On the evening of February 28, 2020, Let’s Encrypt found a bug in the code that checks CAA records — the DNS records that say which certificate authorities are allowed to issue for a domain. Instead of rechecking every name on a certificate before issuing, it had sometimes rechecked one name and stamped the rest. The certificates were fine in the sense that the domains were validly controlled. They were not fine in the sense that the CA had followed its own rules. So they had to go.
The count was 3,048,289 certificates — about 2.6% of the roughly 116 million Let’s Encrypt certificates active at the time. The revocation was set for March 4 at 20:00 UTC, which gave the internet a little under five days to replace three million certificates. And here is the part that matters: Let’s Encrypt’s only tool for making that happen was a blog post and a flurry of emails. There was no button. The CA that had automated certificate issuance down to an API call had no automated way to tell three million servers “the thing you’re running is about to be revoked — renew it now.”
They didn’t make the deadline. More than a million certificates were nowhere near being replaced in time, so Let’s Encrypt postponed revoking them rather than break a million sites over a paperwork error. The revocation happened, mostly, and the web mostly survived, but the incident exposed something embarrassing about how automated the “fully automated” certificate ecosystem actually was. Renewal — the one operation that has to happen on a schedule, forever — was the part the CA couldn’t reach.
Who Was Deciding When to Renew
Before this, the renewal date was a guess your client made. Certbot and the other ACME clients pick a time — commonly when the certificate is two-thirds through its life, or a fixed number of days before it expires — and renew then. It’s a reasonable heuristic, and it has one enormous blind spot: it’s static. The client decides once, based on the expiry date printed in the certificate, and nothing that happens afterward changes its mind. The CA discovering it mis-issued your cert is not printed in the certificate. Neither is the CA realizing that half its customers all renew at 3 a.m. UTC on the first of the month because that’s when everyone’s cron job fires.
So you had two problems wearing the same clothes. The dramatic one was revocation: no channel for “renew now, something’s wrong.” The boring one was load: millions of clients renewing on self-chosen schedules that clump into spikes, hammering the CA’s infrastructure at predictable moments for no reason other than that nobody coordinated. Both are the same missing piece — the CA has opinions about when you should renew, and no way to voice them.
What ARI Actually Adds
ACME Renewal Information, published in 2025 as RFC 9773, is that missing channel, and it is almost aggressively simple. The CA exposes a new resource, renewalInfo. Your client takes an identifier derived from the certificate it’s holding and makes a plain GET request to that endpoint. The CA answers with a small JSON object containing a suggestedWindow — two timestamps, start and end — that says “renew this certificate somewhere in here.” There’s an optional explanationURL if the CA wants to point at a page explaining why, and a Retry-After header telling the client how often to check back.
The client’s job is to pick a uniformly random time inside that window and renew then. If the suggested time is already in the past, it renews immediately. That’s the whole protocol. No new cryptography, no handshake changes, no certificate format churn — just a periodic question (“when should I renew this?”) and an answer the CA is now allowed to give.
The randomness is the load fix hiding in plain sight. When every client picks a random point inside a CA-provided window instead of the same deterministic offset, the renewal spikes flatten into a smooth curve. Let’s Encrypt already runs ARI in production and uses it exactly this way day to day: it hands out windows that spread renewals across its fleet so no single moment gets slammed. You don’t have to care, and that’s the point.
And the Revocation Fix
The dramatic case is the same mechanism with the window shoved forward. During a compliance incident or a mis-issuance event, the CA shrinks the suggested window to now for the affected certificates. Clients that poll renewalInfo — which they do on their normal schedule anyway — see a window that starts in the past, and renew immediately. A future version of the 2020 scramble looks less like a five-day emergency and more like: the CA flips the window, clients pick up the new certificate over the next hours, and then the old ones get revoked, after they’ve already been replaced.
That reordering is the quiet revolution here. For a decade the industry tried to make revocation work as a thing that happens to a live certificate — OCSP asking the CA mid-handshake, CRLs listing dead serials — and all of it failed softly and silently, which is worse than not having it. ARI sidesteps the entire problem. Instead of trying to tell every browser on earth “don’t trust this cert anymore,” you tell the much smaller set of servers holding it “replace this cert now,” and the revocation becomes a cleanup step after the fact rather than a race you’re losing in real time.
The Trade You’re Making
It’s worth naming what changed, because “just turn on ARI” undersells it. Your certificate’s renewal cadence used to be your client’s decision, made from public information in the certificate itself. Now it’s partly the CA’s decision, delivered as a signal your client is expected to obey. Certbot honors ARI by default in recent versions, which means for a lot of people this already happened without a conversation. You’ve handed a dial on your infrastructure’s timing to a third party — a well-run one with good reasons, but a third party.
I think that’s the right trade, and not a close call. The alternative — every operator guessing renewal timing from a static date and hoping nothing changes underneath them — is exactly what turned a routine bug into a three-million-certificate fire drill in 2020. And it stops being optional soon regardless: certificate lifetimes are marching down toward 47 days by 2029, which means renewals happen roughly eight times as often as they did when a cert lasted a year. At that cadence, uncoordinated renewal isn’t a nuisance, it’s a self-inflicted DDoS on your CA. Someone has to hold the schedule. ARI just admits out loud that it should be the CA, and gives it a way to say so.