What changed on 15 March 2026
Two numbers moved at once. The maximum validity of a newly issued public TLS certificate dropped from 398 to 200 days, and the time a CA may reuse a domain validation before re-checking dropped to 200 days as well. Both come from ballot SC-081v3, which the CA/Browser Forum approved in April 2025 with the whole reduction schedule written in from the start.
The practical translation: whoever renewed once a year now renews at least twice, and every CA portal, ACME client and managed platform has been adjusting its defaults around that through 2026. The people who feel it most are the ones who click through a CA’s web interface each summer and install the file by hand, because that workflow just doubled, and it is about to get eight times worse.
The whole schedule, in one table
| Issued from | Max certificate lifetime | Domain validation reuse |
|---|---|---|
| Sept 2020 | 398 days | 398 days |
| 15 March 2026 | 200 days | 200 days |
| 15 March 2027 | 100 days | 100 days |
| 15 March 2029 | 47 days | 10 days |
The last row deserves a second look. From 2029 the certificate may live 47 days, but the proof that you control the domain is only reusable for 10, so issuance effectively re-validates the domain every time. Automated challenges handle that invisibly. Manual validation by email or file upload becomes a monthly chore no one will accept, which is the quiet way the schedule makes automation mandatory without ever saying so.
Why 47, of all numbers
The number looks arbitrary and is the opposite. It is a maximal month of 31 days, plus half of a 30-day month, plus a single day of buffer: 31 + 15 + 1 = 47. The design assumes you renew monthly, gives you two weeks of slack for things going wrong, and one day of grace on top.
The same arithmetic produced the other steps: 200 days is six months plus buffer for a twice-yearly cadence, 100 days is a quarter plus buffer. Every number in the schedule is a renewal rhythm with margin, which tells you how to read the whole thing: the Forum is not really regulating lifetimes, it is regulating cadence.
What this breaks, concretely
Shorter lifetimes are a forcing function, and the things they force out are habits:
- The calendar reminder. Renewal as a yearly human task stops scaling at two renewals and becomes absurd at eight to twelve. Anything that still depends on a person noticing has to move to automation or it will produce outages.
- The reminder email. The old safety net is already gone in the largest case: Let’s Encrypt stopped sending expiry notification emails in June 2025. If your monitoring strategy was an inbox, it ended before the lifetimes shrank.
- Manual install targets. Appliances, load balancers and legacy boxes where a certificate is pasted into a web form. Each of these needs either an automation path or a plan to retire it before 2029.
- Certificate pinning. Pinning a leaf certificate that rotates monthly is unworkable. Pin keys or CAs if you must pin at all.
- Slow change processes. A change-advisory-board cycle that takes three weeks does not fit inside a 47-day lifetime with margin.
None of this is hypothetical staging. The first companies to feel the 200-day step were exactly the ones whose renewal runbook said “yearly, in August”.
Automating in a weekend
The tooling is mature, which makes this one of the rare compliance deadlines that is genuinely cheap to meet early. ACME, the protocol behind Let’s Encrypt, is supported by every major CA now. certbot or acme.sh with a systemd timer covers a classic nginx or Apache box in an afternoon. Caddy and Traefik renew certificates as a built-in behavior. Cloud load balancers from AWS, Google and Azure manage the whole lifecycle themselves. Wildcards and internal hostnames run over the DNS-01 challenge, which wants API access to your DNS zone and repays it by never touching the web server.
The piece that separates a solid setup from a lucky one is independent monitoring. The renewal timer can fail silently for weeks, so something that is not the renewal system must watch notAfter and alert with two weeks of runway. Renewal without monitoring is automation without a seatbelt.
Watching your own dates
Reading the dates takes one paste: the certificate decoder shows notBefore, notAfter and the remaining days for any certificate you drop in, along with the chain it came with. While you are at it, check that the server sends its intermediates, because a renewal that installs the leaf without the chain produces the classic errors dissected in incomplete chain and other SSL errors, and monthly rotation multiplies the chances to get that wrong.
One more reason the era of the long-lived certificate had to end is sitting in the handshake itself: the TLS stack is being rebuilt for post-quantum cryptography, and agility there depends on certificates that rotate fast, a story we take apart in how post-quantum TLS broke old proxies.
Shorter lifetimes, longer questions
Why is my SSL certificate suddenly only valid for six months?
Because since 15 March 2026 public CAs may not issue TLS certificates valid longer than 200 days. Your renewal did not go wrong, the maximum changed. Until March 2026 the cap was 398 days, which is why annual renewal used to fit.
Why exactly 47 days?
It is a calendar sum: 31 days for a maximal month, 15 for half of a 30-day month, plus one day of grace. The idea is a monthly renewal cadence with margin, not a round number for its own sake.
When do 47-day certificates become mandatory?
For certificates issued from 15 March 2029. Before that, the cap drops to 100 days on 15 March 2027.
Why are certificate lifetimes being shortened at all?
Two reasons carried the ballot. A stolen key or misissued certificate stays usable until the certificate expires, because revocation checking has never worked reliably at internet scale, so shorter lifetimes shrink the damage window. And the domain validation behind a certificate goes stale: the shorter the lifetime, the closer the certificate stays to a recent proof that its holder still controls the domain.
Does the 200-day limit affect Let’s Encrypt certificates?
No. Let’s Encrypt has issued 90-day certificates since 2015 and now also offers roughly six-day ones. Its users only feel the 2029 step, when 90 exceeds the 47-day cap and the default lifetime has to drop.
What happens to certificates issued before March 2026?
Nothing. The rules apply at issuance, so an existing 398-day certificate keeps its expiry date. The shorter maximum applies from its next renewal.
Do internal CA certificates have to follow the 47-day rule?
No. The Baseline Requirements bind publicly trusted CAs. A private CA that only your own clients trust can still issue ten-year certificates, and for internal infrastructure that trade-off is often reasonable.
How do I automate certificate renewal?
Use ACME everywhere. certbot or acme.sh with a deploy hook covers classic servers, Caddy and Traefik renew built-in, and cloud load balancers manage certificates themselves. Wildcard and internal names work over the DNS-01 challenge, which needs API access to your DNS zone. The part people forget is monitoring: an expiry check that alerts at 14 days tells you the automation broke while there is still time to fix it.