Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9773.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Most ACME [RFC8555] clients today choose when to attempt to renew a certificate in one of three ways:¶

1. they may be configured to renew at a specific interval (e.g., via cron),¶
2. they may parse the issued certificate to determine its expiration date and renew a specific amount of time before then, or¶
3. they may parse the issued certificate and renew when some percentage of its validity period has passed.¶

The first two create significant barriers against the issuing Certification Authority (CA) changing certificate lifetimes. All three ways may lead to load clustering for the issuing CA due to its inability to schedule renewal requests.¶

Allowing issuing CAs to suggest a period in which clients should renew their certificates enables dynamic time-based load balancing. This allows a CA to better respond to exceptional circumstances. For example:¶

• a CA could suggest that clients renew prior to a mass-revocation event to mitigate the impact of the revocation, or¶
• a CA could suggest that clients renew earlier than they normally would to reduce the size of an upcoming mass-renewal spike.¶

This document specifies the ACME Renewal Information (ARI) extension, a mechanism by which ACME servers may provide suggested renewal windows to ACME clients and by which ACME clients may inform ACME servers that they have successfully renewed and replaced a certificate.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Throughout this document, the word "renewal" and its variants are taken to encompass any combination of "Renewal", "Re-Key", and "Modification" as defined in [RFC3647].¶

This document assumes that the certificates being issued by the ACME server are in compliance with [RFC5280] and, in particular, contain the Authority Key Identifier extension and the keyIdentifier field within that extension.¶

3. Extensions to the Directory Object

An ACME server that wishes to provide renewal information MUST include a new field, renewalInfo, in its directory object.¶

HTTP/1.1 200 OK
Content-Type: application/json

{
  "newNonce": "https://acme.example.com/new-nonce",
  "newAccount": "https://acme.example.com/new-account",
  "newOrder": "https://acme.example.com/new-order",
  "newAuthz": "https://acme.example.com/new-authz",
  "revokeCert": "https://acme.example.com/revoke-cert",
  "keyChange": "https://acme.example.com/key-change",
  "renewalInfo": "https://acme.example.com/renewal-info",
  "meta": {
    "termsOfService": "https://example.com/acme/terms",
    "website": "https://example.com/acme/docs",
    "caaIdentities": ["example.com"],
    "externalAccountRequired": false
  }
}

4. Getting Renewal Information

url = renewalInfo || '/' ||
      base64url(AKI keyIdentifier) || '.' || base64url(Serial)

GET /renewal-info/aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE HTTP/1.1
Host: acme.example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Retry-After: 21600

{
  "suggestedWindow": {
    "start": "2025-01-02T04:00:00Z",
    "end": "2025-01-03T04:00:00Z"
  },
  "explanationURL": "https://acme.example.com/docs/ari"
}

5. Extensions to the Order Object

In order to convey information regarding which certificate requests represent renewals of previous certificates, a new field is added to the Order object:¶

replaces (string, optional):

A string uniquely identifying a previously issued certificate that this order is intended to replace. This unique identifier is constructed in the same way as the path component for GET requests described above.¶

Clients SHOULD include this field in New Order requests if there is a clear predecessor certificate, as is the case for most certificate renewals. Clients SHOULD NOT include this field if the ACME Server has not indicated that it supports this protocol by advertising the renewalInfo resource in its Directory.¶

POST /new-order HTTP/1.1
Host: acme.example.com
Content-Type: application/jose+json

{
  "protected": base64url({
    "alg": "ES256",
    "kid": "https://acme.example.com/acct/evOfKhNU60wg",
    "nonce": "5XJ1L3lEkMG7tR6pA00clA",
    "url": "https://acme.example.com/new-order"
  }),
  "payload": base64url({
    "identifiers": [
      { "type": "dns", "value": "acme.example.com" }
    ],
    "replaces": "aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE"
  }),
  "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
}

Servers SHOULD check that the identified certificate and the New Order request correspond to the same ACME Account, that they share at least one identifier, and that the identified certificate has not already been marked as replaced by a different Order that is not "invalid". Correspondence checks beyond this (such as requiring exact identifier matching) are left up to Server policy. If any of these checks fail, the Server SHOULD reject the new-order request. If the Server rejects the request because the identified certificate has already been marked as replaced, it MUST return an HTTP 409 (Conflict) with a problem document of type "alreadyReplaced" (see Section 7.4).¶

If the Server accepts a new-order request with a "replaces" field, it MUST reflect that field in the response and in subsequent requests for the corresponding Order object.¶

This replacement information may serve many purposes, including but not limited to:¶

• granting New Order requests that arrive during the suggested renewal window of their identified predecessor certificate higher priority or allowing them to bypass rate limits, if the Server's policy uses such;¶
• tracking the replacement of certificates that have been affected by a compliance incident, so that they can be revoked immediately after they are replaced; and¶
• tying together certificates issued under the same contract with an entity identified by External Account Binding.¶

6. Security Considerations

The extensions to the ACME protocol described in this document build upon the security considerations and threat model defined in Section 10.1 of [RFC8555].¶

This document specifies that renewalInfo resources are exposed and accessed via unauthenticated GET requests, a departure from the requirement in RFC 8555 that clients send POST-as-GET requests to fetch resources from the server. This is because the information contained in renewalInfo resources is not considered confidential and because allowing renewalInfo to be easily cached is advantageous to shed the load from clients that do not respect the Retry-After header. As always, servers should take measures to ensure that unauthenticated requests for renewal information cannot result in denial-of-service attacks. These measures might include ensuring that a cache does not include superfluous request headers or query parameters in its cache key, instituting IP-based rate limits, or other general best-practice measures.¶

Note that this protocol could exhibit undesired behavior in the presence of significant clock skew between the ACME client and server. For example, if a server places the suggested renewal window wholly in the past to encourage a client to renew immediately, a client with a sufficiently slow clock might nonetheless see the window as being in the future. Similarly, a server that wishes to schedule renewals very precisely may have difficulty doing so if some clients have skewed clocks (or do no implement ARI at all). Server operators should take this concern into account when setting suggested renewal windows. However, many other protocols (including TLS handshakes themselves) fall apart with sufficient clock skew, so this is not unique to this protocol.¶

7. IANA Considerations

Appendix A. Example Certificate

-----BEGIN CERTIFICATE-----
MIIBQzCB66ADAgECAgUAh2VDITAKBggqhkjOPQQDAjAVMRMwEQYDVQQDEwpFeGFt
cGxlIENBMCIYDzAwMDEwMTAxMDAwMDAwWhgPMDAwMTAxMDEwMDAwMDBaMBYxFDAS
BgNVBAMTC2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEeBZu
7cbpAYNXZLbbh8rNIzuOoqOOtmxA1v7cRm//AwyMwWxyHz4zfwmBhcSrf47NUAFf
qzLQ2PPQxdTXREYEnKMjMCEwHwYDVR0jBBgwFoAUaYhba4dGQEHhs3uEe6CuLN4B
yNQwCgYIKoZIzj0EAwIDRwAwRAIge09+S5TZAlw5tgtiVvuERV6cT4mfutXIlwTb
+FYN/8oCIClDsqBklhB9KAelFiYt9+6FDj3z4KGVelYM5MdsO3pK
-----END CERTIFICATE-----

Acknowledgments

My thanks to Roland Shoemaker and Jacob Hoffman-Andrews for coming up with the initial idea of ARI and for helping me learn the IETF process. Thanks also to Samantha Frank, Matt Holt, Ilari Liusvaara, and Wouter Tinus for contributing client implementations, and to Freddy Zhang for contributing an independent server implementation. Finally, thanks to Rob Stradling, Andrew Ayer, and J.C. Jones for providing meaningful feedback and suggestions that significantly improved this specification.¶

Author's Address