Writing

TLS certificate lifetime: 200 days now, 47 later

Published 26 September 2026

The maximum lifetime for a newly issued public TLS certificate is 200 days from 15 March 2026. It drops to 100 days on 15 March 2027 and 47 days on 15 March 2029. Existing certificates keep their original expiry date. The schedule changes how often certificates must be issued; it does not turn a working certificate into an expired one on each transition date.

A 200-day SSL certificate is therefore the longest a public CA can issue in the current phase, not the lifetime every provider must use.

The TLS certificate lifetime schedule

CA/Browser Forum ballot SC-081v3 changed the Baseline Requirements followed by publicly trusted certificate authorities and browser root programs. The maximum validity period depends on the date the certificate is issued.

The requirements define a day as 86,400 seconds and advise certificate authorities not to issue for the absolute maximum by default. This avoids a fractional second or other boundary condition pushing a certificate over the limit.

These are ceilings, not promised product lifetimes. A certificate authority can issue shorter certificates. Let's Encrypt's classic profile still uses 90 days in 2026, its opt-in tlsserver profile uses 45 days, and its shortlived profile uses 160 hours. All comply with the current 200-day maximum.

What the rule covers

The schedule applies to publicly trusted TLS server certificates: the leaf certificates presented by public websites and services whose chains end at roots trusted by browsers and operating systems. It does not impose the same dates on a private certificate authority used only inside one organization. Private PKI still needs a lifetime policy, but that policy belongs to the organization and its clients.

A renewal is a new issuance, so the rule in force on the renewal date applies to the new certificate. The old certificate remains a separate object with its own notAfter value. Buying a multi-year service plan also does not create one multi-year certificate; the provider issues replacement certificates during the subscription.

Why 200 days still exposes manual renewal

A 200-day certificate needs issuance roughly twice a year. That sounds manageable until an estate has separate certificates on appliances, load balancers, Kubernetes ingresses, mail gateways, vendor portals and disaster-recovery endpoints. The 100-day and 47-day phases remove the remaining margin for a calendar reminder and a person copying files.

The real failure is often after issuance. The ACME client obtains a valid certificate, but the service never reloads it; the certificate lands on one node but not its peers; DNS validation works only from one automation host; or a hardware appliance accepts the leaf but not the intermediate chain. Shorter lifetimes make each hidden manual step recur more often.

Test the renewal path, not the expiry date

1. Inventory every public hostname and IP endpoint. Include alternate ports, IPv6, standby regions and vendor-managed edges.
2. Identify who issues each certificate and which protocol or API performs renewal.
3. Run a staged or forced renewal before the normal window, without replacing the production certificate by hand.
4. Prove the new certificate reached every serving node and that each process reloaded it.
5. Check the complete chain and hostname from outside the network.
6. Alert on renewal failure and deployment failure, then keep an independent expiry alert as the last safety net.

The Kodura SSL checker reads the certificate a public endpoint serves and reports its dates and chain. A command-line check is useful in automation:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -startdate -enddate -serial

Run the same check against each address when DNS returns several endpoints. One successful handshake does not prove every member of a pool was updated.

Use the certificate's lifetime, not a fixed calendar

A job that always renews on day 60 happens to fit a 90-day certificate and fails with a 45-day one. Modern ACME clients can use ACME Renewal Information (ARI), where the certificate authority supplies a renewal window. This lets the authority move a certificate earlier during an incident and spread routine renewals instead of concentrating them at one fixed age.

Let's Encrypt recommends checking ARI at least twice a day. Without ARI, its backstop is to renew when one third of the certificate's lifetime remains. Large deployments should renew in small, staggered groups so one CA outage, DNS problem or broken deployment does not put the entire estate against the same deadline.

Short-lived IP address SSL certificates already show the end state: Let's Encrypt's public IP certificates use the 160-hour profile, so unattended renewal is part of the product rather than an optional convenience.

Domain validation expires separately

Certificate lifetime and validation reuse move together at first, then diverge. From March 2029 a public TLS certificate can last at most 47 days, while the CA can reuse domain or IP validation for only 10 days. A renewal system must therefore be able to prove control again, not merely request a new leaf from an old authorization.

This matters most for DNS-01 workflows. If renewal still requires a person to create a TXT record, shorter validation reuse turns that person into the availability dependency. Use narrowly scoped DNS credentials, delegation or another automated challenge method, and test cleanup as well as creation.

What to change in 2026

Do not wait for the 47-day phase to discover whether renewal is automatic. During the active 200-day phase, find certificates renewed by tickets, spreadsheets or memory; replace fixed-age timers; test service reloads; and monitor what clients receive. Keep the current certificate inventory beside its owner, renewal method and deployment target.

The cryptography is not changing in this schedule. Certificate lifetime is separate from protocol work such as post-quantum TLS key exchange. A site can negotiate a modern key exchange and still fail because its ordinary leaf certificate expired on a forgotten proxy.

Sources

• CA/Browser Forum ballot SC-081v3: adopted validity and validation-reuse schedule
• TLS Baseline Requirements: current normative requirements for publicly trusted server certificates
• Decreasing certificate lifetimes to 45 days: Let's Encrypt's product schedule and operator guidance
• Let's Encrypt integration guide: ARI polling, renewal windows, staggering and retry guidance
• Chrome Root Program: Moving Forward, Together: reasons for shorter lifetimes and ARI adoption

The rules and issuer guidance were checked on 26 September 2026.