What ARI is

ARI is an extension to the ACME protocol (defined in RFC 9773, April 2025) that adds a /renewalInfo/<cert-id> endpoint to every ACME-compliant certificate authority. The endpoint returns a JSON object telling the client when to renew a specific certificate.

Instead of the client renewing on a fixed schedule (T-30 days before expiry, say), the client polls ARI and renews when the CA indicates.

Why ARI matters

Before ARI, renewal timing was entirely a client-side decision. Fine most of the time. Catastrophic in a few specific scenarios:

Bulk revocation events

When a CA discovers it needs to revoke a batch of certificates — because of misissuance, a key-material compromise, a policy change, or a cross-signing CA's compromise — it has to somehow tell all the affected clients to renew before their certs are revoked. Historically this was done by email to the customer contact on file. At WebPKI scale, email is unreliable and slow.

ARI lets the CA signal every client of every affected certificate to renew immediately, without any human coordination. Fleet-wide re-issuance happens on the client's polling cadence (typically every 6 hours).

Scheduled key rotation

A CA that rotates a signing key (because of planned HSM retirement, algorithm transition, or compliance milestone) needs to re-issue every outstanding certificate before the old chain is removed from trust. ARI is the mechanism.

Fleet-wide short-lifetime migrations

When Let's Encrypt moved to 64-day defaults in February 2027, ARI lets the CA signal every existing-long-lived cert to renew early into the new short-lifetime regime. Without ARI, the migration is a slow natural-expiry drift over the full life of the longest-outstanding cert.

The response format

A client polls:

text
1GET /renewalInfo/<base64url(AKI || serial)>

The response is JSON:

json
1{
2  "suggestedWindow": {
3    "start": "2026-11-15T00:00:00Z",
4    "end":   "2026-11-20T00:00:00Z"
5  },
6  "explanationURL": "https://ca.example.com/renewal/why/abc123"
7}

Semantics:

The client should renew between start and end.
The client should pick a time uniformly at random within the window (to avoid thundering-herd renewal waves).
The optional explanationURL points at a human-readable page explaining why the CA is signalling renewal — useful when operators notice an unexpected renewal firing.

If the CA wants a certificate renewed immediately, it returns a suggestedWindow.start in the past.

Polling cadence

Clients poll /renewalInfo on a cadence of roughly every 6 hours (configurable per client). The ARI response can include a retryAfter header hint for CAs that want polling to back off.

A certificate that hasn't been polled for more than its suggestedWindow.end is considered either abandoned or behind — clients that follow ARI correctly won't miss a renewal signal unless they're entirely offline.

Client support

As of October 2026:

Let's Encrypt — ARI live in production
ZeroSSL — ARI live
Sectigo — in beta
cert-manager — ARI support in v1.15+
Caddy — ARI support in v2.9+ (native ACME integration)
lego — ARI support in v4.17+
certbot — ARI support in the current main branch

If you're on an older version of any of these, upgrading is the single highest-leverage change you can make for the 100-day transition.

How ARI relates to the broader transition

ARI is the operational backbone of the CA/B Forum's shortening-lifetime roadmap. At 398-day lifetimes, there was always room for the industry to coordinate out-of-band when things went wrong. At 47-day lifetimes, there isn't — the renewal cadence is too fast for email-the-customer-list responses to be timely enough.

Every certificate issued after the 15 March 2027 100-day deadline should be renewed under ARI signalling. Fixed-schedule renewal still works, but it misses the ahead-of-expiry signals that ARI enables.

Common misconceptions

"ARI makes renewal faster." Not exactly — it makes renewal more responsive. Normal expiry-based renewal still happens on schedule; ARI adds the CA-triggered path.

"ARI replaces OCSP / CRL." No. ARI is about renewal timing. OCSP and CRL are about revocation of currently-valid certs. Both mechanisms exist and complement each other.

"ARI is a privacy problem." The CA sees every ARI poll, which identifies which certificates a client holds. This is essentially the same privacy surface as OCSP. For most operators the trade-off is acceptable — the client is the CA's customer, the relationship is public.

ARI