ARI (ACME Renewal Information)

ARI (ACME Renewal Information), published as RFC 9773 in June 2025, adds a renewalInfo endpoint to the ACME directory. The client builds an identifier from the certificate's Authority Key Identifier and serial number, queries the endpoint, and receives a suggested renewal window with start and end times plus an optional explanation URL. It then renews at a randomly chosen moment inside that window, and when ordering the replacement it names the old certificate in a replaces field.

Why it matters

Fixed rules such as "renew 30 days before expiry" break when lifetimes change or when a CA has to revoke early. With ARI, a CA that discovers misissuance can move the window for the affected certificates into the past, and well-behaved clients renew promptly, before revocation takes their sites offline. ARI also spreads renewals over time instead of creating load spikes, and it adapts automatically as maximum validity shrinks to 200, 100 and then 47 days under Ballot SC-081v3.

Example

A renewalInfo response:

{
  "suggestedWindow": {
    "start": "2026-11-20T08:00:00Z",
    "end": "2026-11-21T08:00:00Z"
  },
  "explanationURL": "https://example.com/incident"
}

The client checks this regularly and renews once the current time passes a random point inside the window.

Common misconceptions

• ARI replaces expiry-based renewal logic entirely. Clients should still fall back to a sensible default when the CA does not support ARI or the endpoint is unreachable.
• ARI is a Let's Encrypt-only feature. It is an IETF standard that any ACME CA can implement.
• Every certificate gets the same window. The CA sets the window per certificate, which is how it can target only the certificates affected by an incident.