SSL Certificate Validity 2026–2029: From 398 to 47 Days — What Changes

Short answer: since 15 March 2026 a publicly trusted TLS certificate can be valid for at most 200 days. On 15 March 2027 the limit drops to 100 days, and on 15 March 2029 to 47 days. The schedule comes from CA/Browser Forum ballot SC-081v3, adopted on 11 April 2025, and it binds every public certificate authority — paid or free, DV, OV or EV. If any step of your renewal depends on a person, a calendar reminder or an email from your CA, it will fail somewhere along this road.

Facts verified on 14 October 2026 against the CA/Browser Forum ballot, DigiCert's summary of it and Let's Encrypt's own announcements. Sources are listed at the end.

The schedule at a glance

The last column is the theoretical minimum — renewing on the final day. Nobody sensible does that. With a normal safety margin, the 47-day stage means renewing roughly every month: about 12 renewals per certificate per year.

One more change took effect on 15 March 2026: the organisation details behind OV and EV certificates (the "subject identity information") can now be reused for 398 days instead of 825.

Two numbers changed, and the second one matters more

Maximum validity decides how often you install a new certificate. Domain validation reuse decides how often the CA has to prove again that you control the domain — through a DNS record, an HTTP challenge file or an email.

Today a successful validation can be reused for months, so a fragile validation setup can hide for a long time. From 2029 the reuse window is 10 days, which means practically every renewal triggers a fresh validation. A step that used to run once a year, with someone watching, will run every month, unattended. If the DNS API token has expired or a firewall rule blocks the challenge, you find out when the certificate does.

What about Let's Encrypt?

Let's Encrypt certificates already last 90 days, well inside the new limits. But Let's Encrypt is shortening them too:

• 13 May 2026 — the opt-in tlsserver profile started issuing 45-day certificates.
• 10 February 2027 — the default classic profile moves to 64-day certificates and a 10-day authorization reuse period.
• 16 February 2028 — the classic profile moves to 45-day certificates with a 7-hour authorization reuse period.

Let's Encrypt's own advice is to let the client decide using ACME Renewal Information (ARI), or to renew at about two thirds of the certificate's lifetime. It says plainly that renewing at a hard-coded interval of 60 days will no longer be enough. If your setup renews on a fixed calendar rather than on the time remaining, it has an expiry date of its own.

There is a second, quieter change. On 4 June 2025 Let's Encrypt stopped sending expiration warning emails. The safety net many teams relied on — "if renewal fails, Let's Encrypt will email me" — no longer exists.

Where renewals actually fail

Expired certificates rarely come from nobody trying to renew. They come from a renewal that half-worked:

1. Renewed but never deployed. The new certificate is on disk, but the web server was never reloaded, so it keeps serving the old one until it expires.
2. Copies elsewhere. The certificate was renewed on the origin server, while the CDN, the load balancer, the mail server or the API gateway still holds an uploaded copy.
3. Validation that only worked once. A DNS provider API token expired, DNS moved to another provider, a CAA record blocks the CA, or a firewall stops the HTTP challenge.
4. Manual certificates. A paid OV or EV certificate installed by hand on an appliance or a hosting panel. At 47 days that is up to a dozen manual jobs per certificate per year.
5. The renewal job that disappeared. A cron entry or systemd timer lost in a server migration, or a container rebuilt without it.

The common thread: the renewal tooling reports success, or reports nothing, and nobody checks what visitors actually receive.

Monitor what the internet sees, not what is on disk

An external certificate check connects to your host the way a browser does and reads the certificate that is actually served. It does not care why something went wrong, so it catches all five failures above. A useful check looks at:

• how many days the served certificate has left;
• whether it covers the hostname you are checking;
• whether the chain leads to a trusted root;
• whether it is self-signed, not yet valid or signed with a weak hash;
• when a new certificate appears — the confirmation that a renewal reached production.

Alert thresholds have to follow the certificate's lifetime. A "30 days left" warning is useful for a one-year certificate, but on a 47-day certificate it would fire roughly two weeks after installation, while your automation is behaving perfectly. Fixed thresholds teach people to ignore the alert, and an ignored alert is worse than none.

How AlertSleep handles shorter certificates

In AlertSleep, certificate monitoring is part of every HTTPS monitor rather than a separate product. For each one:

• the certificate is checked every 6 hours;
• warnings go out at 30, 14, 7, 3 and 1 day before expiry — but a threshold is skipped when it is a third of the certificate's lifetime or more, so a freshly renewed short certificate never sets off an alarm;
• you are alerted when the certificate has expired, is not yet valid, does not cover the domain, is self-signed, uses a weak signature hash, has a broken chain or is missing altogether;
• you are told when a new certificate is being served, so you can see the renewal reach production instead of assuming it did.

In practice the thresholds work out like this:

Alerts arrive by email and in the dashboard, and through Slack, Telegram, Microsoft Teams and the other integrations for which you switch on certificate notifications.

Check one domain right now: run it through the free SSL Checker. Leave your email next to the result and we will keep watching that certificate for you and warn you before it expires. Everything else is described on the SSL monitoring page.

A checklist to finish before 15 March 2027

1. List every public hostname with a certificate — websites, APIs, mail servers, CDN endpoints, status pages. Certificate Transparency logs (for example crt.sh) show every certificate ever issued for your domain, including the ones you forgot about.
2. For each one, write down what renews it and whether the process is automated end to end, including the reload or the upload to the CDN.
3. Replace fixed-interval renewal with renewal based on remaining lifetime, or ARI where your ACME client supports it.
4. Test the validation path: the DNS API credentials, their expiry date, CAA records and firewall rules for HTTP challenges.
5. Find the manual certificates on appliances, hosting panels and uploaded CDN configurations, and plan to automate them or move them to managed certificates.
6. Put an external check on every hostname from step 1, so the next failure shows up as an alert rather than a browser warning.

If you want the background on expiry monitoring itself — why certificates expire and what an expired certificate does to a site — read SSL Certificate Expiration: How to Monitor and Avoid Downtime.

FAQ

Do certificates I already have stop working on 15 March 2027?

No. The limits apply to certificates issued on or after each date. A 200-day certificate issued on 1 March 2027 stays valid until its own expiry date.

Does this apply to internal or private certificates?

No. The rules cover publicly trusted TLS certificates issued under the CA/Browser Forum Baseline Requirements. A private CA used inside your company follows your own policy.

Can I avoid the limit by buying an OV or EV certificate?

No. The maximum validity is the same for DV, OV and EV certificates. Paid certificates are more likely to be renewed by hand, so they are usually the first to cause trouble.

Why are certificate lifetimes getting shorter?

A shorter lifetime limits how long a compromised or wrongly issued certificate can be abused, and it reduces dependence on revocation checks, which browsers perform unreliably. It also forces automation, which removes the human step where most renewals go wrong.

How many times a year will I renew at 47 days?

At least eight times per certificate, and about twelve with a sensible safety margin. With full automation that is no more work than one renewal — without it, it is a monthly chore per hostname.

Sources

• CA/Browser Forum — Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods
• DigiCert — TLS certificate lifetimes will officially reduce to 47 days
• Let's Encrypt — Decreasing certificate lifetimes to 45 days
• Let's Encrypt — Ending expiration notification emails