Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)
Extracted elements (25)
STAR certificates replace revocation with expiration: instead of revoking a compromised certificate, the CA simply stops issuing the next short-term certificate in the sequence. This avoids reliance on unreliable revocation mechanisms (CRL/OCSP) by limiting the window of exposure to the certificate's short validity period.
The lifetime-adjust attribute is provided to let clients pre-date certificate validity (left-pad) to accommodate clients with skewed clocks. Research shows ~95% of severe clock skews (clients >24h behind) fall within 6-7 days, suggesting a 5-7 day adjustment covers 97-99% of skewed clients for Web-facing certificates.
Unauthenticated GET for certificate fetching is introduced to improve HTTP cacheability and reduce dependence on ACME server availability. POST-as-GET cannot be cached by on-path HTTP caches, making STAR clients in high-scale deployments (e.g., many CDN edge nodes) critically dependent on server uptime.
A client MUST NOT send a cancellation request for an Order not in 'valid' state, and a server MUST return HTTP 400 with type 'urn:ietf:params:acme:error:autoRenewalCancellationInvalid' for such requests. Explicit revocation via revokeCert is not supported for STAR certificates; a server receiving such a request MUST return 403 with type 'urn:ietf:params:acme:error:autoRenewalRevocationNotSupported'.
After successful cancellation, the server MUST NOT issue any additional certificates for the Order. The server MUST update Order status to 'canceled', MUST set an appropriate 'expires' date, and MUST respond with 403 Forbidden to any requests to the star-certificate endpoint, including a problem document of type 'urn:ietf:params:acme:error:autoRenewalCanceled'.
Even when unauthenticated GET has been agreed upon, the server MUST also allow POST-as-GET requests to the star-certificate resource, maintaining backward compatibility with authenticated access.
For auto-renewal Orders, the status MUST be 'valid' as long as STAR certificates are being issued. A new 'canceled' status is added; cancellation is the only way to terminate an active STAR Order before its end-date.
For expired Orders, the server MUST respond with 403 Forbidden to any requests to the star-certificate endpoint, with a problem document of type 'urn:ietf:params:acme:error:autoRenewalExpired'. The Order resource's state remains 'valid' per the base protocol.
The 'auto-renewal' object MUST be present in the directory meta field if the server supports STAR, allowing clients to discover STAR support and its constraints (minimum lifetime, maximum duration) before placing orders.
The next STAR certificate MUST be made available at the star-certificate URL halfway through the lifetime of the currently active certificate at the latest. The notBefore of the 'next' certificate MUST be set so that it is already valid when published. The server MUST NOT issue any certificates with notAfter after the auto-renewal end-date.
The server SHOULD include 'Cert-Not-Before' and 'Cert-Not-After' HTTP headers in certificate fetch responses. When they exist, they MUST equal the respective fields inside the end-entity certificate. If an intermediary inserts these headers, it MUST ensure the values match the certificate.
When unauthenticated GET is used to fetch STAR certificates, the server SHALL use appropriate cache directives (RFC 7234 Section 5.2) to set the response freshness lifetime such that on-path caches consider the response stale before or at the time the certificate's effective lifetime expires.
To prevent correlation of certificates by ACME account when unauthenticated GET is used, servers SHOULD choose star-certificate URLs in a non-guessable way (e.g., using capability URLs per W3C guidance), consistent with the recommendation in RFC 8555 Section 10.5.
A new 'star-certificate' field (optional, string, URL) is added to the Order object to point to the rolling STAR certificate resource, distinct from the existing 'certificate' field used for standard one-shot certificates.
STAR capability is advertised via a new 'auto-renewal' object in the ACME directory 'meta' field, containing: min-lifetime (required, integer seconds), max-duration (required, integer seconds), and allow-certificate-get (optional, boolean). This object MUST be present if the server supports STAR.
The notBefore and notAfter of each STAR certificate are computed as: notAfter = min(nrd[i] + T, end); notBefore = nrd[i] - max(adjust_client, adjust_server), where adjust_client = min(T, la) and adjust_server = f * T (with 0.5 <= f < 1). The server MUST NOT set notBefore of the first certificate before the auto-renewal start-date.
The Order resource is extended with a mandatory 'auto-renewal' object for STAR certificates, containing: start-date (optional, RFC3339), end-date (required, RFC3339), lifetime (required, integer seconds), lifetime-adjust (optional, integer seconds, default 0), and allow-certificate-get (optional, boolean).
Two new HTTP response header fields are defined for STAR certificate responses: 'Cert-Not-Before' and 'Cert-Not-After', both using HTTP-date format (RFC 7231 Section 7.1.1.2). When present, they MUST equal the corresponding fields inside the end-entity certificate, enabling clients that do not parse certificates to determine validity windows.
Unauthenticated GET (and HEAD) for star-certificate resources is an optional negotiated feature: the server advertises support via allow-certificate-get=true in the directory meta auto-renewal object, and the client requests it per-Order in the newOrder payload. If accepted, the server MUST reflect the attribute in the resulting order object and MUST also continue to allow POST-as-GET.
Four new error types are added to the 'ACME Error Types' registry: autoRenewalCanceled, autoRenewalExpired, autoRenewalCancellationInvalid, and autoRenewalRevocationNotSupported.
Two new fields are added to the 'ACME Order Object Fields' registry: 'auto-renewal' (object, configurable) and 'star-certificate' (string, not configurable). Two new HTTP header fields are registered: 'Cert-Not-Before' and 'Cert-Not-After' (both standard, http protocol).
Two new IANA registries are created under Specification Required policy: 'ACME Order Auto-Renewal Fields' (for fields in the auto-renewal object of an ACME order) and 'ACME Directory Metadata Auto-Renewal Fields' (for fields in the auto-renewal object of the ACME directory meta object).
STAR amplifies denial-of-service risk: a single Order can produce hundreds of certificates, allowing attackers to exhaust CA resources by setting aggressively short lifetimes. The CA SHOULD enforce a minimum auto-renewal lifetime value and/or rate-limit internal certificate generation, accounting for both scheduled renewals and new requests.
STAR certificates eliminate explicit revocation; expiration replaces it. If an attacker obtains the private key and a post-dated first certificate during the window between Order creation and start-date, cancellation is ineffective. It is RECOMMENDED that IdOs place Orders close to the Order's start-date to minimize this window.
The ACME Order state machine is extended with a 'canceled' terminal state. Transitions: valid -> canceled (STAR certificate canceled by IdO); valid -> expired (natural expiration). The existing states pending, ready, processing, valid, and invalid from RFC 8555 remain; 'canceled' is new.