ACME Renewal Information (ARI): letting the CA tell you when to renew

The renewal heuristic that's about to stop working

Most ACME clients renew at a fixed point in a certificate's life. Certbot's default fires when a cert has fewer than 30 days left, which on a 90-day Let's Encrypt cert puts you right around the two-thirds mark. Reasonable rule. It leaves runway to retry on failure, and it's dumb enough that nobody has to think about it.

The catch is that the number is baked into your client, and your client has no clue what the rest of your fleet is doing. Issue 400 certificates over a migration weekend and all 400 hit the 30-day mark on the same weekend three months later. Your renewal cron starts hammering the ACME directory in a tight window, you scrape against rate limits, and any transient failure cascades because everything retries at once. The heuristic can't react to anything, either. If your CA decides a batch of certs has to be replaced now for compliance reasons it never asked your permission for, the two-thirds rule keeps cheerfully waiting until day 60 while the certificate goes invalid underneath you.

That's the gap ACME Renewal Information fills. ARI, standardized in RFC 9773, flips the relationship: instead of your client picking a renewal time from a number it invented at install, the issuing CA tells your client when to renew. Small protocol addition, big consequences. And with 47-day lifetimes arriving by March 2029, it's about to stop being optional in any way that matters.

What ARI actually is

ARI bolts onto the ACME protocol — the same one certbot, acme.sh, Caddy, and lego already speak to get certificates in the first place. The CA advertises a renewalInfo resource in its ACME directory. Your client takes a cert it holds, derives a key from the cert's Authority Key Identifier and serial number, and asks the CA a direct question: for this exact cert, when should I renew?

The CA hands back a suggested window — a start time and an end time. The rule is simple: pick a random moment inside that window and renew then. Not the start, not a fixed offset, somewhere random in the middle. The jitter is the entire point. When ten thousand clients each roll their own time inside an overlapping window, issuance load spreads into a smooth curve instead of a wall. The CA gets to shape its own incoming traffic, because it drew the window.

The response also carries a Retry-After header — a polling hint telling your client how often to check back. ARI isn't one question asked once at renewal time. A well-behaved client polls the endpoint across the whole life of the cert, because the window can move. That's the part that turns ARI from a neat load-spreading trick into something operationally important.

Why the CA moving the window matters

A static window would already earn its keep on load balancing alone. What makes ARI matter is that the window is live. The CA can collapse it.

Picture a mass revocation. A CA discovers — through its own audits, or someone else's report — that a batch of certificates was misissued. A validation bug, a CAA recheck it skipped, whatever. Under the Baseline Requirements the CA is now on a clock: some categories of misissuance carry a 24-hour revocation deadline, others five days. It has to revoke, and it does not care whether your renewal cron is ready.

We have a real catalog of these. In 2020, Let's Encrypt found a bug in how it processed CAA records and had to revoke around three million certificates on roughly a day's notice. In 2024, DigiCert realized it had skipped a CAA recheck for a subset of validations and announced a 24-hour revocation hitting tens of thousands of certs — then extended it after customers, some of them very large infrastructure operators, made it loudly clear they could not rotate that fast. None of this is hypothetical. It's the background radiation of living on the public PKI.

Here's how a mass revocation feels without ARI. You get an email from your CA, assuming you're on a list that gets the email. Or you find out when your own monitoring screams that a production endpoint is serving a revoked cert. Then you're scrambling to figure out which certs are affected and forcing renewals by hand, fighting your own automation the whole way because it thinks everything's fine.

With ARI, the CA collapses the window to "renew now" for exactly the affected certs. Your client, already polling, sees the window has jumped into the past and renews on its next cycle — automatically, ahead of the deadline, no human in the loop. The revocation becomes a non-event. This is the case that sells ARI, and it's why CAs are pushing adoption ahead of the lifetime cuts. At 47-day certs with a relentless renewal cadence, the blast radius of a mass revocation only grows, and scrambling by hand stops being something you can do.

Turning it on

Good news first: if you're running a current client against a CA that supports ARI, you might already have it.

Let's Encrypt has run ARI in production for a while and uses it to steer renewal load day to day. Certbot added support and, in recent versions, honors it by default — it checks the renewalInfo endpoint and overrides its own 30-days-left heuristic when the CA hands over a window. acme.sh, lego, and Caddy's underlying ACME library all support it too, though the version where it flipped to default-on varies. Pin that down. Don't assume.

The steps:

Check your client version. ARI is new enough that an old certbot from a stale distro package won't have it. Snap and pip builds tend to be current; the apt package on an older LTS often isn't. Confirm the version actually ships ARI handling — don't read it off a changelog and hope.

Confirm your CA advertises it. Look at the CA's ACME directory for a renewalInfo field. There? The CA is offering the endpoint. Not there? Your client has nothing to poll and quietly falls back to the old heuristic.

Verify the client is honoring the window, not just supporting it. This is the step everyone skips, and it's the one that bites. A client can support ARI, advertise that it supports ARI, and still ignore the window because of how renewals get scheduled. The classic failure: a renewal cron that runs once a day at 3am. ARI tells your client to renew at a jittered time, but if the renewal command only ever fires during that one nightly slot, the jitter collapses straight back to "3am, same as everyone else" and you've thrown away the whole benefit. Worse — if the window opens and closes between two of your daily runs, you miss it entirely. Run the renewal in dry-run mode and read the logs. A client genuinely using ARI logs that it fetched renewal info and tells you the window it got back. If the logs only ever talk about days-remaining, ARI isn't in the loop. The fix is almost always to run the check far more often than daily — every few hours, hourly even — so the client can act inside whatever window the CA hands it. The check is cheap. It only does real work when ARI says to.

What to do before 47-day lifetimes land

The CA/Browser Forum's SC-081v3 ballot is walking certificate lifetimes down from 398 days to 47 by March 2029, with the 200-day phase already live as of March 2026 and the 100-day phase landing March 2027. Every step up in frequency multiplies the number of renewal events your scheduler has to survive, and multiplies the cost of getting timing wrong. ARI is one of the rare things in this transition that makes your life easier instead of harder. Do the prep now.

Audit which clients in your estate speak ARI. You almost certainly run more than one. The certbot on your edge boxes. The lego baked into your ingress controller. The acme.sh someone set up three years ago on a server nobody logs into anymore. Some honor ARI, some don't, some are too old to know the word. Get an inventory before the windows start mattering.

Treat the window as fleet-wide telemetry. It isn't only an instruction to one client — it's information about every cert sharing that issuer. When a CA starts collapsing windows across a batch, that's an early signal of a revocation in progress, often before any formal announcement reaches your inbox. Read those windows across the whole estate instead of letting each client consume its own in isolation, and ARI becomes a monitoring source.

Watch for the renewal that started but never finished. This is the dangerous gap. ARI says the window's open. Your client renews and gets a fresh cert. But getting the cert is not deploying it. The new cert still has to land on the load balancer, the key still has to reach the pods, the reload still has to actually happen. A lot of outages come from a cert that renewed cleanly in ACME and never made it onto the thing serving traffic. An open window with no matching deployment is exactly the signal you want surfaced — and it's the cross-client, cross-cloud visibility CertPulse exists to give you: checking whether the cert actually presented on an endpoint matches the one your CA already told you to rotate to.

ARI doesn't replace your monitoring and it doesn't replace good deployment hygiene. What it does is move the "when to renew" call to the only party that knows about emergencies before they're public — the CA. In a world of 47-day certs and shrinking revocation deadlines, that's a decision you want out of a hardcoded constant and into a live signal. Turn it on, prove it's actually working, and stop guessing at two-thirds.