ACME Renewal Information (ARI): how your CA tells you when to renew.

Written by Kirk Diamond · Published 2026-10-20 · 6 min read

The problem it solves

When a CA discovers it has issued certificates incorrectly, the industry rules give it as little as 24 hours to revoke them, and five days in most other cases. Before ARI, the only way to get subscribers to replace those certificates in time was email, which reaches a shared mailbox nobody reads. The certificates were revoked while still in use, and sites went down.

Renewal timing had a second, quieter problem: everyone renewed at the same point. CAs see spikes on the hour from cron jobs, and a wall of renewals 60 days after any day they issued a lot. ARI lets the CA spread them out.

How it works

ARI was standardised as RFC 9773 in 2025. A CA that supports it lists a renewalInfo URL in its ACME directory. A client asks that URL about a certificate it holds, using an identifier built from two things in the certificate: the issuer's key identifier and the serial number, each base64url-encoded, joined by a dot. No account or authentication is needed; the identifier says which certificate, nothing more.

GET https://acme-v02.api.letsencrypt.org/acme/renewal-info/uVnyjs8i8IbTN0j_dhQYuoLYVYc.BUOTO-OGs6KzrdU08hA7yLZf

HTTP/1.1 200 OK
Retry-After: 21600

{
  "suggestedWindow": {
    "start": "2026-11-02T17:18:36Z",
    "end": "2026-11-04T12:29:25Z"
  }
}

The client picks a random moment inside the window and renews then. Retry-After says how long to wait before asking again; clients usually check a few times a day. Some CAs add an explanationURL, a page that says why the window is where it is. Google Trust Services has included one on every answer I have seen; elsewhere it tends to appear when something has happened.

When it renews, an ARI-aware client also tells the CA which certificate the new order replaces. Let's Encrypt exempts those orders from its rate limits, so a client that follows ARI can always renew when asked to, even in the middle of a mass revocation when everyone else is trying to as well.

What a normal window and an early window look like

A normal window sits about two thirds of the way through the certificate's life. For a 90-day certificate issued on 4 September, that is late October or early November. When a CA plans to revoke, it moves the window into the past, so that every client checking sees "renew now". A window that starts before the halfway point is the signal to look for. The SSL certificate renewal checker reads the window for whatever certificate a server is presenting and flags one that has moved early.

Which CAs and clients support it

All five list a renewalInfo URL in their directory as of October 2026. To check any other CA, fetch its directory and look for the key: curl -s <directory> | jq .renewalInfo.

On the client side, certbot (4.1 and later), Caddy and lego follow ARI. If your client does not, it still renews on its own schedule, which is fine until the day the CA needs it to renew early. That is when ARI support matters, and the day to find out is not that one. Check your client's changelog and upgrade if it needs it.

Querying it by hand

The easiest way is the renewal checker's JSON:

curl -s "https://kirkdiamond.com/tools/cert-renewal?host=example.com&format=json" | jq .ari

Or with OpenSSL and curl, for a certificate from Let's Encrypt (change the URL for another CA). The serial is padded to whole bytes, and gets a leading zero byte if its top bit is set, because the identifier uses the DER encoding of the number:

host=example.com
echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null | openssl x509 > cert.pem
b64url() { xxd -r -p | base64 | tr '+/' '-_' | tr -d '=\n'; }
aki=$(openssl x509 -in cert.pem -noout -ext authorityKeyIdentifier | tail -n +2 | tr -d ' :' | sed 's/^keyid//')
serial=$(openssl x509 -in cert.pem -noout -serial | cut -d= -f2)
[ $(( ${#serial} % 2 )) -eq 1 ] && serial="0$serial"
case "$serial" in [89A-Fa-f]*) serial="00$serial";; esac
curl -s "https://acme-v02.api.letsencrypt.org/acme/renewal-info/$(printf %s "$aki" | b64url).$(printf %s "$serial" | b64url)"

A 404 that says the authority key identifier did not match a known issuer means you asked the wrong CA.

Why it matters more as lifetimes shrink

With 47-day certificates, renewal stops being an annual chore and becomes something that happens every few weeks without anyone looking. ARI is how the CA steers that: it spreads the load, pulls renewals forward when it must, and tells you why. A setup that renews automatically, follows ARI and reloads the server afterwards is a setup that survives a CA's bad day without anyone being paged.