Every SSL certificate carries two timestamps: a moment it becomes valid and a moment it stops. The second one causes a remarkable share of the internet’s avoidable outages — sites that worked perfectly on Monday showing full-page warnings on Tuesday because a date passed. It is reasonable to ask: why do certificates expire at all?

Expiry is a security feature

A certificate is a claim — “the holder of this key controls this domain” — that was true when a certificate authority checked it. Claims go stale. Domains change hands, companies dissolve, private keys leak, and cryptographic standards move on. Expiry puts an upper bound on how long a stale or stolen claim can keep working:

It limits key exposure. If a private key is stolen and nobody notices, the thief can impersonate the site — but only until the certificate expires. Shorter lifetimes shrink that window.
It forces revalidation. Renewal re-runs the proof that you still control the domain, so certificates cannot outlive ownership by years.
It lets the ecosystem upgrade. Rules improve — SHA-1 signatures banned, 1024-bit keys retired. Because everything expires, old certificates age out on a schedule instead of lingering for decades. (Revocation exists too, but it is patchy in practice — expiry is the backstop that always works.)

This is why lifetimes keep shrinking. Certificates could once last five years; the browser root programmes cut the maximum to two years in 2018, then to 398 days in 2020, and the industry is committed to going much shorter over the coming years. Let’s Encrypt has issued 90-day certificates from the start — a deliberate choice to make automation the only sane option.

How renewal actually works

“Renewal” is a slightly misleading word: you do not extend the old certificate, you obtain a completely new one and swap it in. Either way, the process has the same three steps: prove you control the domain, receive the new certificate, and install it (with its chain) on the server. What differs is who does those steps — you, or software.

The automated route: ACME and Let’s Encrypt

ACME (Automatic Certificate Management Environment, RFC 8555) is a protocol that automates the whole cycle. An ACME client on your server — certbot is the best known, with acme.sh, Caddy and built-in support in many proxies — talks to a CA, proves domain control, fetches the certificate and installs it, on a timer, forever. Proof takes one of two forms:

HTTP-01 — the client serves a challenge file at /.well-known/acme-challenge/; the CA fetches it. Simple, but the server must be reachable on port 80.
DNS-01 — the client publishes a TXT record; the CA queries it. Slightly more setup (API access to your DNS), but works behind firewalls and is required for wildcard certificates like *.example.com.

Let’s Encrypt — a non-profit CA — made this route free, which is why over half the web now runs on it. Its certificates last 90 days, and clients renew from about 30 days before expiry, so a healthy setup renews six times a year without anyone noticing. Google Trust Services, ZeroSSL and others offer free ACME certificates too, and most managed hosts and CDNs (Cloudflare, Netlify, and the rest) run the same machinery for you behind a checkbox.

The manual route: paid CAs

Paid certificates from CAs such as DigiCert, Sectigo or GlobalSign still have their place — organisation and extended validation, warranties, support contracts, and niches like BIMI’s Verified Mark Certificates that genuinely require a paid product. Encryption strength, however, is identical: a free DV certificate protects traffic exactly as well as a paid one.

The real cost of the paid route is operational: if issuance involves a human downloading files from an email link and pasting them into a control panel, renewal depends on that human remembering. Most “our website is showing a security warning” incidents are exactly this — the certificate did what it said on the label, and the calendar reminder failed. Many paid CAs now support ACME as well, which is worth enabling for that reason alone.

When it goes wrong

An expired certificate fails loudly: browsers show NET::ERR_CERT_DATE_INVALID, API clients throw errors, mail delivery breaks. Browsers and clients may warn users or reject secure connections to the domain entirely — and high-profile names (Microsoft Teams in 2020, Spotify, government portals) have all been caught out. The fix is always the same: issue a new certificate, install it with its full chain, and reload the server. Recovery is immediate — certificates have no propagation delay.

Making expiry a non-event

Automate if you possibly can. ACME on your own servers; the built-in certificate management on managed platforms.
Test the timer, not just the certificate. A renewal that stopped (an expired DNS API token, a firewalled port 80) fails silently until expiry. Check that the last renewal actually happened recently.
Monitor externally. Check your domains with the SSL expiry checker — if a certificate is inside 30 days and automation should have renewed it, something is wrong now, while there is still time.
Cover all the names. Renewal only helps names on the certificate. If www and the apex are served separately, check both — a wildcard or SAN certificate can consolidate them.

Want the check right now? Run your domain through the SSL checker — the verdict leads with the expiry countdown, and Tech mode shows the validity dates exactly as the certificate states them.