Certificate lifetimes are collapsing to 47 days and your renewal process is a person

The CA/Browser Forum passed the ballot to step maximum TLS certificate validity down in stages — 398 days now, then 200, then 100, then 47 days by March 2029. Domain validation reuse periods shrink alongside it, down to about ten days at the end state.

The reaction split cleanly into two groups, and which group you’re in tells you everything about your infrastructure.

Group one shrugged. They’ve been renewing every 60 days on ACME since 2016 and the number changing from 90 to 47 is a config value they’ll never look at.

Group two started drafting objections, because somewhere in their organisation is a calendar reminder, a spreadsheet, and a person who downloads a file from a portal once a year.

The argument for it

Certificate revocation has never worked. That’s not a controversial claim, it’s the consensus position of everyone who’s looked at it.

CRLs are enormous and stale. OCSP added a real-time lookup that leaked user browsing to the CA, cost a round trip, and — critically — failed open, because failing closed would have meant a CA outage taking down half the web. So browsers soft-failed, which means an attacker who can block the OCSP request also defeats revocation entirely. OCSP stapling fixed the privacy and latency problems for the sites that deployed it, which was never most sites. Major browsers have been walking away from live revocation checking for years in favour of pushed CRL sets covering a subset of cases.

So: when a private key is compromised, the honest answer about how quickly that certificate stops being trusted is “it mostly doesn’t, until it expires.”

Given that, validity period is the revocation mechanism. A 398-day certificate is a 398-day window. A 47-day certificate is a 47-day window. That’s the whole argument and it’s correct.

The argument against it, which is also correct

Short lifetimes convert a rare manual task into a frequent one. Frequent manual tasks get automated or they fail — and the failure mode of certificate renewal is a total outage of the service, at a moment nobody scheduled.

For everything with a well-supported ACME client and a normal web server, fine. For the rest of the estate, this is genuinely hard:

• Network appliances whose certificate upload is a web form with a session timeout.
• The industrial controller with a five-year support contract and no ACME anything.
• Client certificates in a mutual-TLS mesh where both ends have to rotate.
• Certificate pinning in a mobile app that ships on the store’s release schedule, not yours.
• Anything embedded, air-gapped, or from a vendor that no longer exists.

The people objecting to this ballot are not lazy. They’re running estates where a meaningful fraction of endpoints have no automation path at all, and the deadline is not negotiable with the browsers.

I called this wrong in 2020

When lifetimes dropped from 825 days to 398, I said it was the browsers offloading their revocation failure onto everyone else’s operations team. Fix revocation, I said, don’t make expiry the workaround.

That position hasn’t aged well, and the reason is that I was arguing for a fix that was never going to arrive. Revocation’s problems are structural — privacy, availability, and the fail-open requirement are in tension in a way that no protocol revision resolves. Twenty years of attempts produced OCSP stapling, which helped, and Must-Staple, which nobody deployed. Waiting for a better mechanism was waiting for something that wasn’t coming.

And the forced-automation argument turned out to be the real payoff, in a way I didn’t credit. The estates that automated because 398 days made manual renewal annoying are now strictly better run than they were — they have an inventory, they have monitoring, they know what certificates exist. The organisations that never automated didn’t have those things either. Shortening the period didn’t just improve revocation. It flushed out the parts of the estate nobody was tracking.

That’s a real benefit and it only happens under pressure. I don’t love that, but pretending otherwise would be dishonest.

What to do now, not in 2028

Inventory first. You cannot automate what you cannot enumerate. Certificate Transparency logs will tell you about every publicly-trusted certificate ever issued for your domains, including the ones a team stood up in 2022 and forgot. crt.sh and a script will find things that surprise you.

Automate the easy 90% immediately. ACME on everything that speaks it. This is well-trodden ground and the clients are mature.

Make the remaining 10% a project with a name and a budget. These are the appliances and the vendor gear. Some need firmware updates, some need a proxy in front of them terminating TLS, some need to be replaced. All of those take procurement time, which is measured in quarters, which is why this starts now.

Monitor expiry as a first-class alert. Not “we’ll notice.” An actual check, at 21 days and 7 days, that pages someone. When the validity period is 47 days, a renewal process that silently broke six weeks ago is an outage you have already scheduled and not yet experienced.

The date is fixed. The only variable is whether you find your unautomatable endpoints on your own schedule or on the browsers’.