The dates
In April 2025 the CA/Browser Forum, where the certificate authorities and the browser makers agree the rules for public certificates, passed ballot SC-081. It was Apple's proposal, and every major browser voted for it. It sets a falling maximum on how long a publicly trusted TLS certificate may be valid, and on how long a CA may reuse a check that you control the domain:
| Issued on or after | Maximum lifetime | Domain validation reuse |
|---|---|---|
| Before 15 March 2026 | 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 limit applies when a certificate is issued. A one-year certificate bought on 14 March 2026 is valid until March 2027, and nobody can make it stop early. Its replacement is what gets shorter. Most CAs issue a day or so under the limit (199 days at the moment) to leave room for clock skew.
Some CAs are moving faster than the rules. Let's Encrypt, which already issues 90-day certificates, has announced 64-day certificates by default from February 2027 and 45 days from 2028, and offers six-day certificates to anyone who asks.
Why it is happening
Revocation does not work well. When a certificate's key leaks or a CA issues one it should not have, the certificate is revoked, but browsers check revocation patchily or not at all, so a revoked certificate keeps working until it expires. A shorter lifetime is the only revocation that every client honours. The same goes for domains changing hands: a certificate validated for the previous owner should not outlive their ownership by a year.
The other reason is agility. Moving the web to new algorithms, post-quantum ones included, means replacing every certificate. If the whole web already replaces its certificates every few weeks, a change of algorithm is just the next renewal rather than a multi-year project.
What it means in practice
Renewing with a third of the lifetime left, which is what ACME clients do by default, the numbers come out like this:
| Lifetime | Renewals a year | Renewed every |
|---|---|---|
| 398 days | 1 or 2 | about 9 months |
| 200 days | about 3 | about 4 months |
| 100 days | about 6 | about 2 months |
| 47 days | about 12 | about a month |
The validation column catches out more people than the lifetime. Today an organisation can prove control of its domain once and have its CA issue against that for most of a year. From 2029 the proof is good for ten days, so it has to be repeated for nearly every renewal. That is easy for an ACME client answering an HTTP or DNS challenge, and very hard for a process that involves someone clicking a link in an email.
Private CAs are not affected. A certificate from your own internal CA, trusted only by your own machines, can still last as long as you like. The rules are for certificates that browsers trust by default.
What breaks first
In my experience the certificate itself is rarely the problem. What fails is everything around it that assumed it changed once a year:
- Manual renewal. A calendar reminder, a purchase order, a CSR generated on someone's laptop, a zip file from the CA's portal, a change request to install it. Doing that once a year is tedious; twelve times a year it will not happen reliably.
- Appliances that only take uploads. Older load balancers, firewalls, VPN concentrators, NAS boxes and printers whose only way in is a web form. They cannot run an ACME client. Put a proxy that can in front of them, use the vendor's ACME support if a firmware update adds it, or script the upload against their API.
- Renewed, not deployed. The ACME client renews and writes the file, and the server keeps serving the old certificate from memory because nothing reloaded it, or the new file reached one machine out of four. With yearly certificates there were months to notice. With 47-day certificates there are about two weeks.
- Pinning. Mobile apps and partner integrations that pin the leaf certificate or its key break on every renewal. Pin the CA's intermediate or root key instead, or stop pinning.
- Certificates copied into other systems. The same certificate pasted into a CDN, a SaaS custom domain, a mail gateway and a monitoring tool. Each copy is a separate renewal.
- Client authentication. Public CAs stopped putting the clientAuth usage in server certificates in 2026, under the Chrome root programme's rules. Anything that used a web certificate to authenticate itself to another server, for mutual TLS between companies, some mail relays, XMPP federation, breaks at its next renewal, whatever its lifetime.
How to check where you stand
Put each public hostname through the SSL certificate renewal checker. It connects to every address the name resolves to and reads the certificate each one serves. A short certificate from an ACME CA is almost always renewed by a client; one long certificate from a commercial CA usually is not. When one address already serves a newer certificate and another still has the old one, nearly expired, that is the renewed-not-deployed case. It also asks the CA when it wants the certificate renewed (that is ACME Renewal Information).
From a terminal, a loop over your hostnames gives a list to work through:
for h in example.com www.example.com api.example.com; do
printf '%-24s ' "$h"
curl -s "https://kirkdiamond.com/tools/cert-renewal?host=$h&format=json" \
| jq -r '"\(.ready) \(.automation) \(.lifetime_days)d \(.ca)"'
done
Do not forget the names nobody browses to: the mail server's certificate, the VPN endpoint, the API host your mobile app uses, the admin interface on a non-standard port.
How to get ready
- Automate with ACME. certbot, acme.sh, lego, Caddy (which does it without being asked), win-acme on Windows, and the ACME support in most reverse proxies and Kubernetes ingress controllers. Let's Encrypt and Google Trust Services are free; most commercial CAs, DigiCert, Sectigo and GlobalSign among them, now offer ACME with an account key if you need their certificates.
- Reload on renewal. Every ACME client has a hook for it:
--deploy-hook "systemctl reload nginx"for certbot,--reloadcmdfor acme.sh. A renewal that does not reload anything is a renewal you have not done. - Let the platform do it. If a CDN, a cloud load balancer or a managed certificate service (AWS Certificate Manager, Cloudflare, Google-managed certificates) terminates TLS, let it issue and renew too. Shorter lifetimes become its problem.
- Use DNS validation where HTTP does not reach. Internal hosts, wildcards and anything behind a firewall can still get public certificates by answering a DNS challenge through your DNS provider's API.
- Allow a second CA. Check your CAA record permits a fallback, and configure one in the ACME client if it supports it. A CA outage of a few days matters much more when certificates last 47 days.
- Monitor the served certificate, not the file. Alert on days left on what the server presents, from outside. Under a third of the lifetime left with nothing newer in the logs means the automation has stopped. Which certificate expired, and why has a check you can run from CI.
If you do one thing this year, find the certificates that are renewed by hand. There are always more than anyone thinks, and March 2027 is the date their renewals double.