Why SSL Certificates Keep Shrinking — the 2-Year → 1-Year → 90-Day → 10-Day Story
My blog doesn’t know what a certificate renewal is. It sits behind Cloudflare, and Cloudflare’s own certificate tooling re-issues TLS certificates on its own schedule — before the old one even hits its birthday. I never think about it. Every large operator I know runs the same silent loop. That dull background hum is the secret reason certificate lifetimes have been shrinking for a decade, and it’s about to get a lot more aggressive.
If you manage any TLS certificate by hand, the next few years are going to change your life — whether you pay attention or not.
First, a decoder ring for the numbers you keep hearing
The headline everyone repeats — “2 years → 1 year → 90 days → 10 days” — smashes two different clocks together. Let me unstick them, because only one of them is about how long your certificate is valid:
| Label | What it actually is | Clock |
|---|---|---|
| 2 years (825 days) | Max certificate validity, 2018 | Validity |
| 1 year (398 days) | Max certificate validity, 2020–2026 | Validity |
| 200 days | Max certificate validity since 15 Mar 2026 | Validity |
| 90 days | Proposed by Google in 2023 — was NOT adopted | Validity (proposal) |
| 47 days | Agreed maximum validity by 15 Mar 2029 | Validity |
| 10 days | Max time you can reuse a previous domain validation | Revalidation data |
The phrase most people quote — “certificates are going to 10 days” — isn’t actually true for certificate validity. 10 days is the domain-revalidation reuse window that’s coming in 2029. Your certificate still lives for 47 days; but the proof you did about the domain only stays good for 10 days. Those are two separate lifespans that people keep merging into one scary number.
And the sharpest distinction: 90 days never became a rule — Google proposed it in 2023, but it did not make it into the binding ballot SC-081. The lifetime that is actually scheduled is 47 days by 2029. When you hear “certs are going to 90 days,” you are hearing a proposal, not a requirement.
Why shrink certificates at all? The security reasoning
A certificate is a claim about the present moment: “at the time this was issued, we checked that this domain belongs to this party, and this is the key that speaks for it.” The longer that claim stays alive, the more out of date it becomes, and the longer a stolen key gives an attacker a window of trust. Shorter validity is, fundamentally, a bet that truth decays fast — so the artifact that carries truth should decay with it.
The real engine: “let it expire” beats “revoke it”
The deepest reason is a shift in how we invalidate trust. With a long-lived certificate, the day your key leaks begins a frantic emergency: you must convince every browser cache and every CA to stop trusting a certificate that was valid and still has years to run — via revocation mechanisms (CRL or OCSP) that are famously unreliable and inconsistently checked. With a short-lived certificate, there’s no emergency broadcast at all. You just stop renewing it, and trust dies quietly on its expiry date — in seconds, with zero coordination. Revocation becomes a rounding error instead of the critical path.
The two real pushes: 90 days (Google) vs 47 days (the law)
Let’s Encrypt proved the entire thesis years ago by issuing free, roughly-90-day certificates with full automation — demonstrating that short issuance is not just survivable but effectively the norm. Then, in March 2023, Google published a roadmap proposing a 90-day maximum. That exact number was never adopted. Apple’s counter-proposal — effectively “shorter than 90” — became the formal ballot SC-081v3, which the CA/Browser Forum passed in April 2025, reaching 47 days by March 2029 through 200 and 100 days. To state it precisely: 90 was a proposal that lost; 47 is the figure that became binding law.
How automation proves you own the domain: HTTP-01 vs DNS-01
Since the whole survivable future depends on automation, here is the mechanism under the hood. Before a CA will sign anything, it makes you prove you control the domain. ACME automates that proof through a challenge, and the two you will actually meet are HTTP-01 and DNS-01.
HTTP-01 is the simplest: it only needs a reachable web server that can serve one file on port 80. DNS-01 reaches into your DNS provider to drop a TXT record, which makes it the tool of choice for wildcard certificates and for automating renewals even when the server is behind NAT or offline at renewal time.
| Attribute | HTTP-01 | DNS-01 |
|---|---|---|
| Proof lives in | a file at /.well-known/acme-challenge/ |
a _acme-challenge TXT record |
| Needs a public reachable web server | Yes | No |
Wildcard (*.example.com) support |
No | Yes |
| Typical automation use | simple DV on a web host | wildcard + CI-driven renewals |
| Gotcha | port 80 must stay answerable | DNS provider must allow automated TXT writes |
Whichever challenge you pick, the client handles it and the renewal loop runs itself — which is exactly why short certificates stopped being a burden and became a gift. The proof is automated, so the expiry is a feature, not a chore.
The validity ladder that is now law
For a single certificate, the practical rhythm drifts from “renew once a year” to “renew about eight times a year.” Multiply that by an enterprise estate — DigiCert’s own research says the average large org runs 50,000+ certificates and two in three have already suffered an outage from an expiring one. The schedule is engineered, in the ballots’ own words, to be “reasonable and attainable” — but only attainable with automation. This is the ballot’s real goal: it forces the manual-renewal crowd to either build automation or go home.
The second clock: domain revalidation drops to 10 days
This is where the fabled “10 days” actually lives. When you renew via automated domain validation, you don’t always re-prove ownership from scratch each time — the CA remembers the last proof and reuses it, up to a cap. That reuse cap is being crushed to 10 days by 2029. The point is that no stale proof survives long enough to be weaponized — a mis-issued certificate’s validation ancestry rots almost immediately. It’s the same “truth decays” philosophy, aimed at the evidence instead of the certificate. (Slightly tin-foil reading: it also makes full automation effectively mandatory, because no human is re-validating domains every ten days.)
What this means for you (and why it’s not scary)
| Your situation | What to do now |
|---|---|
| Manual certs on your own server | Move to an ACME client and test a 60-day rotation immediately |
| Heavy enterprise estate | Stand up a certificate lifecycle manager and inventory every cert this week |
| Site behind a CDN / managed cloud | Do nothing — but confirm the platform renews automatically |
| Still on pen-and-paper renewals | Book the migration now; by 2029 manual renewal is effectively impossible |
The fear around shrinking lifetimes mostly comes from the manual crowd. Shorter certificates are more secure and, with automation, less work — the machines renew themselves. The genuine risk is only for the humans still calendaring it in Outlook.
The one-line takeaway
SSL/TLS certificates aren’t getting shorter out of malice — security is pushing them down, automation is what makes that survivable, and “10 days” is about re-proving your domain, not about your certificate expiring. If you’re not automated yet, 2027 is your deadline to get there.
Sources: CA/Browser Forum Baseline Requirements & Ballot SC-081v3 (approved 11 Apr 2025); DigiCert & The SSL Store summary of the SC-081 phased schedule; Let’s Encrypt 90-day pioneering practice.