Your SSL Certificate Is Expiring and Nobody Told You (Until Now)

There's a special kind of production incident where nothing changed in your code, no deploy went out, and yet everything is on fire. Nine times out of ten, that's an SSL certificate that quietly expired at 3 AM on a Sunday.

It's one of the most avoidable outages in web development, and also one of the most common — because certificates don't fail loudly in advance. They just work, right up until the exact second they don't.

Why this keeps happening

Certificates aren't a "set once" thing. Most are valid for 90 days (shorter than they used to be, thanks to Let's Encrypt and browser vendors pushing shorter lifespans) or up to a year for some paid CAs. That means renewal is a recurring chore, not a one-time setup step — and recurring chores are exactly the kind of thing that fall through the cracks when:

• The person who set up the cert three renewal cycles ago has left the team
• Auto-renewal (certbot, ACME, load balancer integration) is assumed to be working but silently isn't
• A subdomain or staging environment was added later and never got its own monitoring
• The cert is fine, but the chain is incomplete — valid on your server, broken on some clients

That last one is sneaky. A certificate can look perfectly fine in your own browser (which caches intermediate certs) while failing for a fraction of your users whose devices don't have the intermediate cert cached — usually because the server isn't sending the full chain.

What "checking your SSL" actually means

It's not just "is it expired." A proper check covers:

• Expiry date — obviously, but also how soon. 30 days out is a warning; 3 days out is an incident.
• Chain completeness — is the full chain (leaf → intermediate → root) being served, or just the leaf cert?
• Hostname match — does the certificate actually cover the domain (and subdomains, if it's a wildcard) being served?
• Protocol and cipher support — is the server still allowing deprecated protocols like TLS 1.0/1.1 that some compliance frameworks and browsers now flag or block?
• Issuer trust — is it signed by a CA that's actually in modern trust stores, and not self-signed in a production context?

Missing any one of these can mean "works for me" while a meaningful slice of real users get a scary browser warning or an outright connection failure.

The cost of getting this wrong

• Browsers don't politely degrade on an expired or mismatched cert — they show a full-page warning that most non-technical users won't click past.
• API clients and mobile apps often fail harder than browsers — no warning screen, just a TLS handshake error and a support ticket.
• SEO and trust signals take a hit; search engines and security scanners both penalize broken HTTPS.
• Compliance audits (PCI-DSS, SOC 2, etc.) will flag weak protocols or incomplete chains even if the site "works."

The frustrating part is that all of this is checkable in advance — it just requires actually looking, on a schedule, instead of finding out when a customer emails you.

A faster way to look

Rather than pulling out openssl s_client every time (which, fine, works, but nobody wants to remember the flags), I built a quick certificate checker that surfaces expiry date, days remaining, chain status, and issuer info for any domain in one pass:

👉 SSL Certificate Checker

It's part of samtoolkit.com — small, client-side developer tools (JWT decoder, HTTP status/header reference, webhook bin, env validator, and others). Nothing you check gets logged or stored server-side.

If you've had a cert-expiry outage story, I'd genuinely like to hear it in the comments — everyone has one, and they're always more avoidable in hindsight than they felt at 3 AM.