The maximum validity of a publicly trusted TLS certificate is falling from 398 days to 47 days in three steps. The first step took effect on March 15, 2026: certificates issued since then can be valid for at most 200 days. The next steps are 100 days from March 15, 2027 and 47 days from March 15, 2029. At the same time, the period a certificate authority (CA) may reuse a past check of your domain falls from 398 days to 10.

The rules come from Ballot SC-081v3, which the CA/Browser Forum adopted on April 11, 2025, and they now live in the Baseline Requirements, the rulebook every publicly trusted CA follows.

The schedule

The limits apply by issue date. A certificate is judged by the rule in force on the day it was issued, so nothing already issued gets cut short.

Certificate issued Maximum validity Domain validation reuse
Before March 15, 2026 398 days 398 days
From March 15, 2026 200 days 200 days
From March 15, 2027 100 days 100 days
From March 15, 2029 47 days 10 days

The figures are the hard maximums (MUST NOT) from sections 6.3.2 and 4.2.1 of the Baseline Requirements (version 2.3.1, October 2026). Each validity step also has a recommended maximum (SHOULD NOT) one day shorter: 397, 199, 99 and 46 days. The same section asks CAs not to issue for the maximum permissible time by default. For these calculations, a day is exactly 86,400 seconds.

400 200 0 2025 2026 2027 2028 2029 2030 Days of validity, by issue date 398 days 200 days 100 days 47 days
Maximum validity of a publicly trusted TLS certificate by the date it is issued. Source: Baseline Requirements, section 6.3.2.

On the day this guide was last updated, the 200-day limit is in force. A certificate issued today can be valid until early May 2027 at the latest, and anything issued on or after March 15, 2027 will last 100 days or less.

Where the numbers come from

The CA/Browser Forum is the body where certificate authorities and browser makers (the “certificate consumers”) agree the rules for publicly trusted certificates. Changes are made by ballot. SC-081v3 was proposed by Clint Wilson of Apple and endorsed by Sectigo, Google Chrome and Mozilla. Voting closed on April 11, 2025:

  • Certificate issuers: 25 yes, 0 no, 5 abstaining.
  • Certificate consumers: 4 yes (Apple, Google, Microsoft and Mozilla).

The change entered the Baseline Requirements as version 2.1.5, effective May 16, 2025, according to the document’s revision table. No later ballot has altered the schedule; the current version still carries the same tables.

The ballot’s own rationale is worth reading in full. Two lines sum it up: a reduction to both lifetimes and reuse periods “increases the average net reliability of certificates”, and a shorter lifetime “provides firm protection to users, independent of certificate status services”. In plain terms: certificate details, domain ownership and keys go stale, and revocation has never worked well enough to clean up after them. Shorter lifetimes limit how long a stale or mis-issued certificate can be trusted.

Domain validation reuse matters more than the lifetime

Before issuing a certificate, a CA must confirm you control the domain, for example by fetching a token over HTTP or looking up a DNS record. Until March 2026 a CA could reuse that proof for up to 398 days, so a renewal often needed no new check at all. The reuse window now shrinks on the same dates as the lifetime, but ends much lower: 10 days from March 15, 2029.

With a 47-day certificate renewed roughly every month and a 10-day reuse window, practically every renewal will need a fresh domain check. That has consequences that are easy to miss:

  • HTTP validation needs port 80 reachable from the CA at every renewal, not once a year. Firewall rules, redirects and maintenance pages all get in the way.
  • DNS validation needs working API credentials for your DNS provider at every renewal. Expired tokens and rotated keys turn into failed renewals.
  • CAA records (which name the CAs allowed to issue for your domain) are checked each time too. A change of CA without updating CAA blocks issuance.

Organization details for OV certificates (the “Subject Identity Information”) can be reused for 398 days since March 15, 2026, down from 825. EV certificates already had a 398-day limit under the EV Guidelines.

What it means in renewals per year

Shorter maximums mean more renewals. The table assumes you renew with a third of the lifetime left, which is what Let’s Encrypt recommends as a backstop.

Maximum validity Renew after Renewals per certificate per year
398 days about 265 days 1.4
200 days about 133 days 2.7
100 days about 67 days 5.5
47 days about 31 days 11.6

A team with 40 certificates renewed by hand would go from around 55 renewals a year to around 465. That is the real argument of the schedule: renewing by hand goes from an occasional chore to a monthly job for every certificate.

Let’s Encrypt is moving faster than the rules

Let’s Encrypt issues 90-day certificates today and is shortening them ahead of the Baseline Requirements:

  • Since January 15, 2026, its opt-in shortlived profile issues certificates valid for 160 hours, just over six days (announcement).
  • From May 13, 2026, its opt-in tlsserver profile issues 45-day certificates (plan).
  • On February 10, 2027, the default profile switches to 64-day certificates with a 10-day authorization reuse period. The staging environment switches on October 14, 2026, and Let’s Encrypt expects the last 90-day certificate to expire on May 11, 2027 (announcement).
  • On February 16, 2028, the default becomes 45-day certificates with a 7-hour authorization reuse period.

Its October 2026 post gives one very practical tip: search your scripts, cron jobs and runbooks for hardcoded renewal intervals such as 60, 80 or 83 days. With a 64-day certificate, 80 and 83 renew after it has expired, and 60 leaves four days of margin; with a 45-day certificate, all three fail.

How to prepare

Automate issuance with ACME

ACME (RFC 8555, March 2019) is the protocol that lets a client prove domain control and fetch a certificate without a human. Most public CAs support it, and so do most web servers and platforms, either built in (Caddy, Traefik, cert-manager on Kubernetes, many hosting panels) or through a client such as Certbot, acme.sh or lego. If a certificate is still renewed by someone downloading a file from a CA’s website, start there.

Stop hardcoding the renewal interval

A client that renews “every 60 days” breaks the moment the lifetime drops below 60. Renew relative to the certificate’s own validity instead, or better, ask the CA. ACME Renewal Information (ARI, RFC 9773, June 2025) lets the CA suggest a renewal window for each certificate. Let’s Encrypt’s integration guide recommends checking ARI at least twice a day, and renewing with a third of the lifetime left as a backstop (halfway, for certificates valid for less than 10 days).

Make domain validation boring

Pick one validation method per hostname and make it work unattended: port 80 open to the CA for HTTP-01, or a scoped API token for DNS-01 that does not expire on a calendar nobody watches. Keep your CAA records in step with the CAs you use.

Keep an inventory

List every hostname that serves a certificate, where the certificate is installed (load balancer, CDN, mail server, appliance, internal tool) and what renews it. The certificates that hurt are the ones nobody remembers: a paid certificate uploaded to a firewall by hand, a staging host, a mail server on port 465. A renewal process that takes an afternoon twice a year will need to happen every month by 2029.

Watch what is actually served

A renewal can succeed while the server keeps serving the old certificate, because it was never reloaded or the new file went to the wrong path. Check expiry from the outside, the way a visitor sees it. The guide to checking a certificate’s expiry shows how with a browser, OpenSSL, curl or a few lines of code.

Set alert thresholds below your normal renewal point, so an alert means a renewal did not happen. Expiry Watch checks daily and emails at 30, 14, 7, 3 and 1 day before expiry; for certificates renewed with a third of their life left, the later alerts are the ones that mean something went wrong.

Common questions

Do certificates I already have get shorter?

No. Every limit applies to certificates issued on or after its date. A 398-day certificate issued on March 14, 2026 stays valid until it expires.

Does this apply to certificates from my own internal CA?

The Baseline Requirements govern publicly trusted TLS server certificates, the ones browsers and operating systems trust out of the box. A private CA that only your own devices trust is not bound by them, although the software that uses its certificates may set its own limits.

Why 47 days?

The ballot does not say. One reading that fits: 47 days is a 31-day month plus about two weeks, enough to renew every month with a margin for a failed attempt or two.

Is 10-day domain validation reuse a problem for ACME?

Not if renewal is automated: ACME clients already complete a validation at each order whenever the CA asks for one. It is a problem for manual processes and for setups where the validation path only works some of the time.

Sources

All sources were checked on October 14, 2026.