How long is an SSL certificate valid? The shrinking certificate lifespan

The SSL certificate validity period for any publicly trusted TLS certificate is currently capped at 398 days — roughly 13 months — and that ceiling is about to drop sharply. If you're asking how long an SSL certificate lasts, the short answer is "less every year": the CA/Browser Forum has approved a phased reduction that takes the maximum down to 200 days in 2026, 100 days in 2027, and just 47 days in 2029. This post explains the current limit, how the industry ratcheted down to it, the exact schedule that's coming next, why it keeps shrinking, and what it means for how you run renewals.

The current maximum: 398 days

Since 1 September 2020, no publicly trusted leaf certificate may be issued with a validity period longer than 398 days. The limit isn't written into the TLS protocol — it's enforced by the root programs that decide which certificates browsers trust. Apple announced the policy first, and Google (Chrome) and Mozilla (Firefox) aligned with it. A certificate issued for longer than 398 days will simply be rejected by those clients, regardless of what the CA put in the notAfter field.

That 398 figure is deliberately a little more than a calendar year. It's 397 days for the certificate plus a one-day grace allowance, which gives you room to issue a "one year" certificate without tripping the limit on a leap year or an off-by-one at the boundary. In practice, a cert you buy today as "1 year" lands somewhere just under 398 days.

You can read any certificate's own validity window directly. The dates are baked into the cert as notBefore and notAfter:

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

notBefore=Jan  1 00:00:00 2026 GMT
notAfter=Feb  3 23:59:59 2027 GMT

The span between those two lines is the validity period. For more ways to inspect a cert from the command line, see check an SSL certificate with openssl.

A short history of the ratchet

Certificate lifetimes have been shrinking for over a decade. Each step was driven by the same logic — a shorter-lived certificate is a smaller liability — and each was met with the same complaint that it would be operationally painful. The trend line is unmistakable:

• 8–10 years. In the early days of commercial SSL, multi-year certificates were normal. You could buy a cert and forget about it for most of a decade.
• 5 years. An early cap brought the maximum down to 60 months.
• 39 months (~3.25 years). The CA/Browser Forum's Baseline Requirements set this as the ceiling for several years.
• 825 days (~27 months). Effective 1 March 2018, the maximum dropped to 825 days, ending the era of multi-year certs.
• 398 days (~13 months). Effective 1 September 2020, the current limit, driven by the browser root programs.

Each cut roughly halved the previous window. The direction has only ever been down, and the cadence is accelerating.

What's coming: the phased drop to 47 days

In 2025 the CA/Browser Forum approved ballot SC-081 — the "Sunlight" proposal originally brought by Apple — which sets a staged reduction of the maximum validity period over the next several years. Rather than one abrupt cut, it phases the ceiling down on fixed dates:

| Effective date | Maximum certificate validity | |---|---| | Today | 398 days | | 15 March 2026 | 200 days | | 15 March 2027 | 100 days | | 15 March 2029 | 47 days |

The reuse period for domain validation shrinks on the same timeline. Today a CA can reuse a prior domain-control validation for up to 398 days; under the approved schedule that window contracts in step with the certificate maximum, eventually to around 10 days. In other words, you won't just re-issue certificates more often — you'll re-prove control of the domain more often too.

The end state, 47 days, is not an accident of arithmetic. It's built to fit comfortably inside a calendar quarter (roughly a month and a half) with margin for retries, so an automated client has multiple chances to renew before a cert lapses. At that cadence, a certificate that "starts" today is already near the middle of its life by the time most teams would notice it by hand.

Why lifespans keep shrinking

The ceiling keeps dropping for three connected reasons, and none of them are about making your life harder for its own sake.

Limiting the damage window. A certificate is a standing assertion that a particular key belongs to a particular domain. If the private key is compromised, or the certificate was mis-issued, that assertion is dangerous for exactly as long as the certificate remains valid. A 47-day certificate caps the blast radius of a compromise at 47 days; a 398-day certificate leaves the door open for over a year.

Reducing reliance on revocation. When a cert goes bad mid-life, the only remedy is revocation — and revocation is the weak link in the web PKI. Certificate Revocation Lists (CRLs) are large and cached; the Online Certificate Status Protocol (OCSP) historically soft-fails, meaning clients that can't reach the responder often proceed anyway. (Major CAs and browsers are now actively retiring OCSP in favor of CRL-based mechanisms, which only reinforces the point.) If certificates simply expire faster, revocation matters less, because a bad cert ages out on its own.

Forcing automation. A 200-day cert is awkward to renew by hand; a 47-day cert is impossible to keep up with manually across more than a handful of hosts. Short lifetimes are, in part, a deliberate push to make ACME-based automation (Let's Encrypt, ZeroSSL, ACME-capable commercial CAs) the default rather than the exception. Automated issuance is also better hygiene: it encourages fresh keys, tested renewal pipelines, and certificates that are continuously, rather than occasionally, correct.

What this means for you

The era of buying a certificate, installing it, and circling a renewal date a year out is already ending — and within a few years it'll be gone entirely.

Manual annual renewal is on borrowed time. If your process today is a calendar reminder and a person, it already strains at 398 days. At 100 days you'd be renewing every quarter; at 47 days, every six weeks. That's not a workflow a human should own. Adopt ACME automation now, before the shorter windows make it mandatory rather than merely advisable.

Automation has to actually work — and prove it. More renewals means more opportunities for a renewal to silently fail: a hook that doesn't fire, a server that renews the file on disk but never reloads, a wildcard that quietly stops covering a host. Each shortened lifetime multiplies the number of these events per year. Automation reduces the per-event risk but increases the event count, which is exactly why independent monitoring becomes more important, not less, as lifetimes fall.

Internal and private CAs are a different story. The 398-day ceiling (and the schedule below it) applies to publicly trusted certificates — the ones in the browser and OS trust stores. If you run your own private CA for internal services, mTLS between microservices, or an air-gapped environment, you set your own validity periods and can still issue multi-year certs if you choose. That distinction matters for planning: your public edge will be on a 47-day cadence while your internal PKI may not be. Both still need watching — see monitoring internal and private SSL certificates.

How to check any certificate's validity window

Whatever the policy maximum, the only number that matters operationally is what's actually in the certificate you're serving. Pull the dates straight off a live host:

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

Or read them from a certificate file on disk:

openssl x509 -noout -dates -in /etc/ssl/certs/example.com.crt

To see only the expiry line:

openssl x509 -noout -enddate -in /etc/ssl/certs/example.com.crt

notAfter=Feb  3 23:59:59 2027 GMT

If you want a step-by-step on extracting and interpreting these fields — including SANs and issuer — see how to check an SSL certificate's expiration date. If a cert has already crossed its notAfter date, clients hard-fail with errors like CERT_HAS_EXPIRED, and there's no graceful fallback.

Shorter certs mean monitoring matters more

There's a simple multiplication at the heart of all this. With 398-day certificates, a given host renews about once a year — one chance per year to miss it. At 100 days that's roughly four renewals a year; at 47 days it's around eight. Across a fleet of domains, subdomains, and SAN entries, the number of individual renewal events you depend on goes up by 8× over the same period. Every one of those events is a chance for automation to fail quietly.

Automation lowers the odds that any single renewal fails. It does nothing to lower the count of renewals, and a renewal pipeline that works 99% of the time still leaves you exposed when you're running thousands of renewals a year. The only thing that closes that gap is an independent check that verifies what's actually being served, on a schedule, regardless of whether your renewal job thinks it succeeded. That's why teams pair ACME automation with proactive expiry alerts — the automation does the work, the monitor confirms the work happened. For the broader picture of what to watch beyond the expiry date, see the SSL certificate monitoring guide.

Monitor it automatically

As certificate lifespans shrink from 398 days toward 47, the cost of a missed renewal stays the same — an outage — while the number of renewals you have to get right keeps climbing. SSLNudge checks your certificates every day, reads the real notAfter date being served, and alerts you well before each one expires, so a renewal that quietly failed becomes a notice instead of downtime. Add your domains once and let the daily check keep pace with the shorter windows. Sign in to start monitoring.