Abstract
On March 19th, Richard Hicks, one of our customers, emailed us about a certificate that had renewed after only a week. It was a 90-day certificate and he had not initiated the renewal.
That’s the kind of thing that sends you straight to the logs.
We found the answer right away. The certificate’s ARI renewal window had been shortened dramatically. Instead of a comfortable 60-day window, the renewalInfo endpoint was returning a window that had already elapsed, which is the ARI signal for “renew this certificate right now.”
We traced the explanationURL field in the ARI response back to a Let’s Encrypt community forum post: they were running a mass revocation simulation.
What Let’s Encrypt did
On March 19, 2026, Let’s Encrypt ran their first annual mass revocation drill. The simulated scenario involved about 3 million certificates that had been “incorrectly issued” and needed to be replaced.
The drill had two parts. In staging, the affected certificates were actually revoked. In production, nothing was revoked, but the ARI renewal windows were shortened to signal an emergency. Any ACME client properly implementing ARI would see the shortened window and renew the certificate immediately. The old certificate would continue to work. The point was to test whether clients would respond to the signal.
They announced it on the Let’s Encrypt community forum, but didn’t send anything to users. After all, if everything is automated, this should just work.
Mozilla Root Store Policy v3.0, which took effect in 2025, requires every CA in Mozilla’s root program to maintain and annually test a mass revocation plan. The policy language is flexible: CAs can satisfy the requirement with tabletop exercises, simulations, parallel testing, or test environments “which do not involve the revocation of active certificates.”
A tabletop exercise is just a meeting where you walk through the plan on paper. Most CAs will just do that.
Let’s Encrypt didn’t stop at a tabletop. They picked 3 million real production certificates, shortened their ARI windows to signal an emergency, and watched what happened.
What happened on our end
For clients that properly implement ARI, the drill was invisible (unless you keep an eagle-eye on your renewals). The client polls the renewalInfo endpoint, sees the shortened window, and renews. If it also sends the replaces field on the new order (as the RFC requires), the CA can revoke the predecessor immediately and waive rate limits.
Every CertKit-managed certificate included in the simulation renewed and deployed automatically. Our monitoring flagged the unusual timing before Richard even emailed us, and everything was replaced within the emergency window without anyone touching it.
Clients that don’t implement ARI had no idea the drill happened. Nothing broke, because the certificates weren’t actually revoked in production. But that’s the whole point: finding out who would respond if something real happened.
I’ll update this post when they release their findings, but we already have a rough answer from history. When Let’s Encrypt had to revoke 133,613 certificates in September 2024 over a real compliance issue, only about 5.6% renewed via ARI. The other 94% weren’t listening.
The two most popular ACME clients have a timing problem. Certbot checks ARI only when its scheduled job happens to run, which could be days or weeks. acme.sh has no ARI support at all. In a real revocation event with a 24-hour deadline, that means an outage and manually forcing renewals.
As certificate lifetimes keep shrinking, these drills will matter more. The whole bet is that automation makes mass revocations invisible.
Comments