← Blog

Why do SSL certificates expire?

January 14, 2026

By Nick Phillips, Founder

If you've ever wondered why SSL certificates can't just be issued once and left alone forever — like, say, a domain registration — you're asking a reasonable question. The answer has a few moving parts, and most of them are about what happens when something goes wrong, not what happens when everything goes right.

The short version

Every SSL/TLS certificate carries two dates inside it: notBefore and notAfter. Anything outside that window is rejected by browsers. Today the maximum lifetime for a publicly-trusted certificate is 398 days, and the industry is in the middle of shortening it further.

The expiration date exists because the certificate is a claim — "this domain belongs to this organization, here's the public key" — and claims that don't have an expiry have to be perfect forever. They never are.

What expiration actually fixes

Three things, in order of how often they matter in practice:

1. Stale information. Certificates bind a key pair to a domain at a moment in time. Companies change names, get acquired, lose control of subdomains, sell domains to other companies. The cert keeps asserting the old binding until something forces a refresh. A short expiration is what forces the refresh.

2. Key compromise. If an attacker steals a private key, they can impersonate the site until either the cert expires or someone notices and revokes it. Revocation, it turns out, is broken in practice — browsers either don't check, check unreliably, or fail open. Expiration is the only mechanism that's guaranteed to work, because it's built into the cert itself. Shorter lifetimes mean a smaller window of compromise.

3. Cryptographic obsolescence. Algorithms get weaker over time. SHA-1 was acceptable in 2010, deprecated in 2016, and is now actively dangerous. RSA-2048 is fine today but won't be forever. Forcing certs to be reissued regularly means the ecosystem can roll forward — a CA can stop issuing SHA-1 certs and the whole web converges in a year, not a decade.

The first two are the practical reasons. The third is the long-term reason. Together they're why "certificates that never expire" is a non-starter.

Why the lifetimes keep dropping

The maximum-allowed lifetime has been a moving target for a decade:

The pattern is consistent: browsers (Apple and Google in particular) decide the previous limit was too long, the CA/Browser Forum either agrees or gets walked into agreeing, and certificate lifetimes drop. There has never been a vote to raise the limit.

The argument for shorter lifetimes is always the same: revocation doesn't work, so expiration has to do the job. The argument against is always the same: shorter lifetimes mean more renewal work for site operators. The browsers don't pay the renewal cost, so the browsers have consistently won that argument.

Why this means you need automation

A 398-day cert is renewed about once a year — annoying but doable manually. A 47-day cert is renewed roughly every six weeks. Nobody is going to do that by hand. You either automate renewal (via Let's Encrypt and ACME, or your CA's API) or you accept that your site will go down every six weeks.

The catch is that "automated renewal" is not the same as "renewal that always works." Certbot is a script that runs on a schedule, and scripts fail. The hosting provider changes their DNS API. The webroot directory gets moved. The renewal succeeds but the reload step silently doesn't pick up the new cert. We've written about the most common Let's Encrypt renewal failures separately — they're worth knowing about even if you're not on Let's Encrypt, because the failure modes are basically universal.

The combination of "renewal is required" + "renewal is automated" + "automation fails silently" is the entire reason this site exists. Otterwatch checks your cert from outside your infrastructure once a day and emails you 30 days before it expires, then again at 7 days, then if it actually expires. It's the smoke detector for the renewal cron that nobody remembers to test.

What this means for "internal" certs

If you run an internal CA — for VPN clients, internal services, IoT devices — the public-trust expiration rules don't apply to you. You can issue 10-year certs to your toaster if you want.

But everything else in this post still applies. Keys still get compromised. Algorithms still go stale. The fact that you've decided not to inherit the browsers' expiration window doesn't mean you've solved the problem it's trying to solve — it just means you've made it your problem to solve another way.

The pragmatic answer for internal PKI is "shorter than you think." A year is reasonable. Five years is a smell. Ten years is a future incident.

How to actually keep track

The simplest answer is the one this whole site exists for: have something else watch the date for you, and email you before the date arrives. You can do that with Otterwatch, with a homegrown cron + openssl s_client script, or with one of the other monitoring tools we compared — what matters is that something is watching, because the cert itself isn't going to remind you.

If you want a one-off check right now, paste a domain into our free SSL checker — it'll show you the expiration date and the issuer in a few seconds, no signup needed. If you want a daily check that emails you ahead of time, that's what you sign up for.

Either way, the answer to "why do SSL certificates expire" is: because the alternative is worse, and the people who decide the rules don't trust us — any of us — to clean up after ourselves any other way.