TLS certificates: lifetimes are being cut to 47 days

What is changing

The maximum lifetime of a public TLS certificate is being cut in stages. The CA/Browser Forum requirements look at the issue date: a certificate issued on or after 15 March 2026 may last no longer than 200 days, from 15 March 2027 no longer than 100, and from 15 March 2029 no longer than 47. Certificates issued earlier live out their full term — nothing is revoked retroactively.

The reduction schedule

Along with the certificate lifetime, the period during which a certification authority may reuse a domain validation it has already performed is shrinking too. That is the second column, and it is the one that hurts manual issuance more.

The row in force today is the one with 200 days. Phrases such as "certificates now live 47 days" are common, but that is the 2029 figure, not the current one.

Why the requirements give two numbers per stage

The text sets a pair of values for every stage: a certificate should not be issued for longer than 199 days and must not exceed 200. For the 2029 stage the pair is 46 and 47. The one-day margin exists because a day counts as 86400 seconds, and leap seconds and fractions of a second round upwards. The practical conclusion: never issue a certificate for exactly the limit.

What this actually breaks

A shorter lifetime breaks nothing by itself — it breaks manual habits. Check four places:

1. Certificates someone renews by hand once a year from a calendar reminder.
2. Certificates baked into container images and application builds.
3. Load balancers and CDNs where the certificate is uploaded separately from the web server.
4. Mail and control-panel certificates: people remember the web server and forget Postfix and the panel.

How to check your own certificates

The lifetime of a given domain is visible without logging in to the server:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates -subject

Every certificate on the server and the time it has left:

for c in /etc/letsencrypt/live/*/cert.pem; do
  echo "$c $(openssl x509 -noout -enddate -in "$c")"
done

Checking that automatic renewal genuinely works rather than merely being configured:

systemctl list-timers | grep -i certbot
certbot renew --dry-run

If --dry-run fails, renewal will not happen on the real day either — deal with it now, not when the certificate expires. Issuance errors are covered in the article on checking an SSL certificate.

What to set up so the reduction never touches you

Proper preparation is not "renew more often" but "never renew by hand at all".

1. Issue and renew through an ACME client on a timer, not from a reminder.
2. Reload services in the renewal hook; otherwise the new certificate sits on disk while the server keeps serving the old one.
3. Validate the domain over DNS if you have many certificates: a wildcard over DNS-01 removes the dependency on every site being reachable over HTTP.
4. Monitor expiry from outside. A server that "renews itself" fails silently exactly once — and once is enough.

Automatic renewal for several domains is covered in the article on auto-renewing wildcard certificates.

ARI: the server tells you when to renew

With short lifetimes it matters not only that you renew, but that the whole planet does not renew at the same moment. ACME has an extension for this, ARI: the certification authority tells the client the window in which it should renew. It is standardised as RFC 9773. Modern clients read it on their own; all the administrator has to do is avoid nailing the renewal schedule to one specific hour.

Let’s Encrypt is moving faster than the requirements

Individual certification authorities already issue for shorter terms than the industry limit. Let’s Encrypt currently offers three profiles:

The shortlived profile lasts roughly 6 days and meets the definition of a short-lived certificate: it needs neither OCSP nor a revocation list. Since 15 March 2026 a short-lived certificate is one valid for no more than 7 days — the threshold used to be 10.

Frequently asked questions

Will my 398-day certificate stop working?

No. The limit applies to the issue date, not the expiry date. A certificate issued before 15 March 2026 will serve out its term; the next one, however, will be shorter.

Does this apply to self-signed and internal certificates?

No. The CA/Browser Forum requirements cover public certificates that browsers trust. Your own internal certification authority is yours to limit.

Can I buy a three-year certificate and forget about it?

No. Such certificates have not been issued since 2020, and the limit keeps falling. A multi-year paid certificate means paying up front with reissues inside the term, not one certificate lasting years. Validation levels are covered in the article on DV, OV and EV certificate types.

What should ZevsHost customers do?

On shared hosting the panel issues and renews certificates automatically — there is nothing to do. On a VPS or dedicated server renewal is yours to run: check the ACME client timer and the service reload in the renewal hook.