How long a yes lasts

Eighty-three. Eighty. Sixty. Those are the numbers Let's Encrypt wants you to grep for in your cron jobs, wrapper scripts and runbooks. On Wednesday the nonprofit said that from February 10, 2027, its certificates will last 64 days by default instead of 90, and that any renewal hard-coded to a day count should move to about two-thirds of the lifetime. Forty-five-day certificates follow in 2028.

Further down the same post is a smaller change with a sharper number. The authorization reuse period, how long Let's Encrypt will trust that you proved control of a domain before it issues again without re-checking, drops from 30 days to 10. In 2028 it drops to seven hours.

Seven hours is the number that matters, because a certificate was never a statement about a key. It is a photograph: at one moment, this applicant answered a challenge for this domain. Lifetime and reuse decide how long the web treats an old photograph as a current one. Shrinking both is the web conceding that the only revocation that reliably works is the clock.

The week supplied the demonstration. On Tuesday Google disclosed that attackers hijacked the .gh, .sl and .as country-code domains, rewrote DNS for selected names beneath them, and passed automated domain validation for "several Google domains" and other large brands. No domain owner was breached. The certificate authorities followed every requirement. The photograph was genuine. It just showed someone else holding the domain.

Google's advice to domain owners is the tell. Publish restrictive CAA records, it said, "to prevent attackers from reusing cached validation data after DNS control is restored." Getting your domain back does not end the attack. A validation cached during the hijack keeps minting certificates for as long as reuse allows, and each certificate stays valid for as long as its lifetime allows. Thirty days of reuse on top of 90 days of validity is four months of trust bought with a single window of control.

That sentence is the whole case for short lifetimes. Revocation reaches the certificates someone finds, through a process Ars describes as slow and cumbersome enough that browser makers built their own blocklists, and Chrome's blocklist protects Chrome. For the certificates nobody finds, expiry is the only revocation that will ever fire.

For the certificates nobody finds, expiry is the only revocation that will ever fire.

The strongest objection is that none of this would have stopped the hijack. That's true. A six-day certificate works fine during the six days an attacker holds your DNS, and this time Chrome's blocklist, not a lifetime policy, contained the damage. Shorter lifetimes also move cost onto operators: every renewal is another chance for an outage, and the appliance that only takes a new certificate through a web form becomes a recurring chore. Those costs are real, but they fail loudly. An expired certificate takes a site down and someone gets paged. A counterfeit certificate fails silently, for as long as the calendar allows. Trading quiet risk for loud toil is the right trade, and ACME Renewal Info, which lets the CA tell your client when to renew, exists so the toil belongs to software rather than people.

The fix Let's Encrypt is asking for takes one grep. The idea behind it reaches well past TLS. Every stack runs on cached yeses: session tokens, API keys, an OAuth grant someone approved in 2023 and nobody has looked at since. Each one is a photograph of a moment, and somebody should know how old it is. For domain control, Let's Encrypt has picked its answer. Seven hours.