ARI (ACME Renewal Information) #

ARI (ACME Renewal Information) is an ACME endpoint that returns, for each certificate, the suggested period in which they should be renewed. ARI enables CAs to automatically inform their users that they must proactively replace their certificates in case they will be revoked due to, for example, a compliance requirement violated by the CA. In addition, ARI also helps to mitigate load spikes on the CA infrastructure by evenly distributing the suggested renewal window across all certificates.

ARI is being standardized in a draft RFC. See the ARI announcement and the ARI integration guide from Let’s Encrypt for more information.

How Does It Work ? #

ACME clients generally run at a scheduled interval (e.g. once a day via cron). Without ARI, most ACME client renew their certificates either a fix amount of time before their notAfter expiry timestamp or after some percentage of their validity period has passed (usually ~70%).

With ARI, ACME clients don’t need to implement their own logic to determine when to renew certificates. Instead, they ask the CA when would be a good time to do it.

To query the suggested renewal window, clients must send, for each certificate, an HTTP GET request to the renewalInfo URL found in the JSON object returned by the ACME Directory URL. Here is how an ARI request looks like.

$ curl -s -H "Accept: application/json" https://dv.acme-v02.api.pki.goog/renewal-info/db7Ed66J9kQ3fc-xaB8dGuvcNFk.AnGD1KgleQcKPY9gnifN5Q | jq

The path of the request URL ends with the base64url-encoded Authority Key ID and Serial Number of the certificate concatenated with a “.” character. Use this CyberChef recipe to easily compute its value.

Click here to view the ARI response.

{
  "suggestedWindow": {
    "start": "2025-05-31T13:30:09Z",
    "end": "2025-05-31T14:30:09Z"
  },
  "explanationURL": ""
}

How Often Should Clients Query the ARI Endpoint ? #

To ensure timely replacement of certificates affected by upcoming revocations, clients should query the ARI endpoint multiple times per day.

Cron-based clients should be configured to run every 4-8 hours. Clients with more flexible scheduling capabilities should honor the Retry-After HTTP header set in ARI responses to determine when to send the next request. CAs may lower its value when they know that a revocation is about to happen.

To ensure that ARI requests aren’t silently failing, clients must also ensure that failures are reported.