A valid certificate the CA wants gone
Picture a certificate with 140 days left on it. Not expiring. Not revoked. By every check your monitoring runs, it looks fine. notAfter is comfortably in the future, the chain builds, the padlock is closed. And yet the CA that issued it wants it replaced today, because something went wrong upstream and that cert is now on a list.
Nothing in the certificate says so. The expiry date hasn't moved a minute. The only place that "replace this now" signal lives is an endpoint most people have never called: ARI, the ACME Renewal Information extension. If your automation isn't reading it, a mass revocation is invisible to you right up until browsers start throwing errors.
That gap stopped being theoretical this year.
What Let's Encrypt rehearsed in March
On March 17, 2026, Let's Encrypt posted a notice on its community forum: it was about to run a mass revocation simulation. Nothing was actually wrong. Mozilla's root store policy now requires every CA in the program to keep a mass-revocation plan and test it once a year, and this was the first run of theirs.
The scenario they picked was a plausible one. A slip against the baseline requirements that would have forced them to reissue a batch of certificates. In staging they went all the way. Issuance stopped, the "affected" certs were actually revoked, then issuance came back once the imaginary bug was "fixed." In production they revoked nothing. Instead they did the thing that matters here. They computed the affected certificates and shortened their ARI windows to say, in effect, renew right now.
That is the whole point of the drill. Revocation is the CA's job. Renewing before the revocation lands is yours, and ARI is the only channel a CA has to tell you the deadline just moved.
How ARI actually works
ARI is RFC 9773, published in June 2025 by Aaron Gable at ISRG, the group behind Let's Encrypt. It came straight out of 2020, when Let's Encrypt had to revoke around three million certificates over a validation bug and had no way to tell clients to hurry. Email was the state of the art back then. Most operators found out when their sites broke.
The mechanism is small. The ACME directory now advertises a renewalInfo endpoint. Your client builds a certificate ID from two fields already sitting in the cert, the Authority Key Identifier and the serial number, each base64url-encoded and joined with a dot, then does a plain GET:
# The endpoint is listed in the ACME directory
curl -s https://acme-v02.api.letsencrypt.org/directory | grep renewalInfo
# Then GET the per-certificate renewal info
curl -s https://acme-v02.api.letsencrypt.org/acme/renewal-info/<certID>
What comes back is a suggested window:
{
"suggestedWindow": {
"start": "2026-09-10T00:00:00Z",
"end": "2026-09-13T00:00:00Z"
}
}
The client picks a random moment inside that window and renews then. The randomness spreads load, so a CA doesn't get a thundering herd every 60 days. And the CA can move the window whenever it likes. In quiet times it sits at roughly two-thirds of the certificate's life. During an incident the CA slides end into the past, and a conforming client reads that as overdue and renews immediately.
You can pull the two halves yourself to see what your client is working from:
openssl x509 -in cert.pem -noout -serial
openssl x509 -in cert.pem -noout -text | grep -A1 "Authority Key Identifier"
Shrinking lifetimes make this non-optional
Static renewal thresholds, the "renew at 30 days left" kind, worked when certificates lived 398 days. They don't survive what is coming. Ballot SC-081v3, which the CA/Browser Forum passed in April 2025, dropped the maximum validity to 200 days on March 15, 2026. That is already in force. It falls again to 100 days in March 2027 and to 47 days in March 2029. Domain validation reuse shrinks to 10 days on the same schedule.
We've written about what the 47-day window does to your renewal cadence. Short version: a hardcoded 30 days is a different slice of the certificate's life every year, and eventually it's longer than the certificate itself. ARI swaps that hardcoded number for one the CA computes and can change under you. You stop guessing when to renew. You also stop being quietly wrong about it as the ceiling keeps dropping.
The rate-limit angle nobody mentions
There's a practical bribe attached. Let's Encrypt's rate limits have wrecked plenty of Friday deploys, and we've complained about them before. ARI comes with an escape hatch. A renewal that happens inside the suggested window and clearly declares which certificate it replaces is exempt from those limits.
That matters most during the exact scenario ARI exists for. If a CA shortens ten thousand of your windows at once, ten thousand renewals that would normally slam straight into the certificates-per-domain ceiling go through instead, because they're flagged as ARI-driven replacements. Skip ARI and you don't only miss the signal. You lose the one path that lets you respond at scale without getting throttled halfway through.
certbot checks ARI, but only when it runs
The common client already does this. certbot added ARI in version 4.1.0, released June 10, 2025. certbot renew now queries the endpoint and will renew early when the window says so, overriding your renew_before_expiry setting if the CA wants the cert gone sooner than you planned.
The catch is buried in that sentence. It checks ARI when certbot renew runs. certbot has no background loop. It polls at the moment the timer fires and not a second otherwise. If your systemd timer or cron runs certbot renew twice a day, which is the packaged default, you'll see an emergency window within twelve hours. Good enough. But if someone "tidied up" the schedule to weekly to be polite to the CA, your emergency response time is now up to seven days, and a shortened window that opens on Monday evening gets spotted the following Monday.
# Check how often renewal actually runs. This is your ARI polling interval.
systemctl list-timers | grep certbot
# The packaged certbot ships a twice-daily timer. Keep it.
The renewal frequency you set to avoid annoying the CA is the same knob that decides how fast you hear about a revocation. Leave it frequent.
cert-manager's ARI is still a feature gate
Kubernetes is where this gets uncomfortable. If you run cert-manager, ARI is off by default. It ships behind an experimental feature gate, ACMEUseARI, that you have to turn on deliberately:
# cert-manager controller args
args:
- --feature-gates=ACMEUseARI=true
And "experimental" is doing real work in that sentence. In July 2026 two issues landed that show where the rough edges still are. #8993 reports that after a renewal actually happens, the stored ARI fields on the Certificate don't get refreshed, so the status drifts out of date. #9028 asks for something you'd expect to already exist, the ability to enable ARI for one issuer and disable it for another, rather than flipping it on globally across the whole cluster.
Neither is fatal. Both mean that if you're leaning on cert-manager to carry you through a mass revocation, turn the gate on now, in a cluster you can watch, and confirm it genuinely re-queries and renews. Don't assume it does. If you're already elbow-deep in cert-manager renewal debugging, we've been there.
What to actually monitor
Here's the shift in thinking. Your monitoring almost certainly watches notAfter, the days until expiry, and pages someone when it drops low. That check is still necessary. It's no longer sufficient, because a certificate can be nowhere near expiry and still be one the CA wants dead.
Poll renewalInfo yourself, out of band. Independent of whatever your ACME client is doing internally, hit the endpoint for your live certificates on a schedule and alert if the window's end is already in the past. That's your CA shouting renew now in a form you can put on a graph.
Keep an external expiry check as the backstop. Whatever the client and the CA negotiate between themselves, something outside your own infrastructure should still look at the certificate a browser actually receives. That's the layer that catches a renewal that succeeded but never got deployed, a failure mode we keep running into.
Renew often, on purpose. Frequent renewal isn't hygiene anymore. It's your polling interval for emergencies. The team that renews twice a day recovers from a mass revocation in hours. The one that renews monthly hears about it from an angry customer.
The 2020 revocation caught the whole ecosystem flat because there was no signal to catch. That excuse is gone. The signal exists, it's standardized, and this year a CA rehearsed sending it. The only open question is whether anything on your side is listening.
Frequently asked questions
Does ARI replace certificate expiry monitoring? No, it sits on top of it. Expiry monitoring tells you when a certificate runs out on its own schedule, while ARI tells you when the CA wants it replaced ahead of that schedule, which is a completely different signal. During a mass revocation the expiry date doesn't move at all, so an expiry-only monitor sees nothing wrong right up to the moment the cert is pulled. Run both, plus an external check on what browsers actually receive.
Will a shortened ARI window break my site on its own? Not by itself. ARI is only advice, and ignoring it changes nothing about the certificate you're serving this second. The breakage comes from what the window is warning about: the CA is about to revoke that certificate. If you don't renew inside the window, you keep serving a cert that gets revoked out from under you, and browsers or clients that check revocation start rejecting it.
How often should my ACME client check ARI?
Often enough that an emergency window doesn't sit around unnoticed. certbot only checks when certbot renew runs, so the packaged twice-daily timer is a sensible floor and daily is about the longest gap you'd want to allow. Don't stretch the schedule out to weekly to be polite to the CA, because that gap becomes your worst-case response time to a revocation.
Is ARI safe to rely on if cert-manager still calls it experimental?
Treat it as real but unfinished. The endpoint and the certbot implementation are stable and running in production today. cert-manager's support works but sits behind the ACMEUseARI feature gate and had open bugs as of July 2026, so if you run it in Kubernetes, enable the gate in a cluster you can observe and confirm it re-queries and renews before you count on it during a real incident.
What did Let's Encrypt's March 2026 simulation actually revoke? Nothing in production. In staging it stopped issuance and revoked the batch of affected test certificates to exercise the full path. In production it revoked no real certificates and instead shortened the ARI windows of the affected set, purely to test whether clients would notice and renew on their own.
