Why Certificates Expire Silently
SSL certificates expire silently because the systems responsible for renewing them fail without ever surfacing an error to a human. Renewal automation — an ACME client, a cloud certificate manager, a hosting provider's built-in renewal — either stops running, runs but fails, or succeeds without the new certificate actually reaching the servers your users connect to. In every variant, no dashboard turns red and no email lands in a monitored inbox; the countdown to the notAfter timestamp just continues. Then, at the exact second the certificate expires, every browser, API client, and webhook sender simultaneously starts refusing to connect. The failure was weeks in the making, but the outage arrives as a cliff. This guide catalogs the specific ways that silence happens, because each one has a different fix — and one shared detection strategy.
Related Reading
What Actually Happens at the Moment of Expiry
A certificate's validity is bounded by two timestamps in the certificate itself — notBefore and notAfter, defined by the X.509 standard (RFC 5280). Clients enforce notAfter with no grace period whatsoever. The instant it passes, browsers show a full-page 'Your connection is not private' interstitial that most visitors will not click through. Mobile apps that pin certificates fail their TLS handshakes outright, usually surfacing as a vague 'network error.' API consumers with default TLS verification — which is to say, nearly all of them — throw certificate errors and stop calling you. Webhook senders like Stripe and GitHub treat the failed handshake as a delivery failure and begin their retry-and-eventually-disable cycle. Monitoring tools that only check for HTTP 200 may keep reporting success if they're configured to skip TLS verification, which is how some teams stay blind through the entire event.
Related Reading
Monitoring a Commercial SaaS?
FourSight's free plan includes 10 commercial-safe monitors with multi-region validation — free forever, no card.
Start Monitoring FreeThe Seven Silent Failure Modes
Post-incident writeups of certificate expiries converge on a small set of recurring causes. If you've operated production systems for more than a couple of years, you will recognize several of these personally.
1. The Renewal Job Died
The certbot systemd timer was disabled during an OS upgrade, the renewal cron entry was lost in a server rebuild, or the container that ran acme.sh was replaced by one that doesn't. The automation isn't failing — it's absent. Nothing logs an error because nothing runs. This is the single most common cause, and it's invisible from inside the box: the machine has no process whose job is to notice a missing process.
2. The Challenge Path Broke
ACME validation requires the certificate authority to reach your infrastructure — over HTTP for HTTP-01 challenges or via a DNS TXT record for DNS-01. A tightened firewall rule, a new redirect-all-to-HTTPS rule that mangles /.well-known/acme-challenge/ requests, or a CDN placed in front of the origin can all break validation. The client runs on schedule, fails, logs the failure to a file nobody reads, and retries into the same wall for 30 days.
3. Credentials Silently Rotated
DNS-01 renewals depend on an API token for your DNS provider; cloud-managed certificates depend on IAM permissions. A routine security rotation, an expired API key, or a permission-boundary change breaks renewal months before the certificate expires. The rotation was correct and deliberate — the renewal dependency on it was just undocumented.
4. Renewed but Never Deployed
The new certificate exists on disk, but the web server never reloaded, the load balancer kept the old cert in memory, or one CDN edge configuration didn't get the update. From the renewal system's perspective everything succeeded. From the internet's perspective, the old certificate is still being served — and still counting down. A missing --deploy-hook that should have run 'systemctl reload nginx' is a classic instance.
5. The One-Off Manual Certificate
Somewhere in your estate is a certificate that was issued by hand for a special case — a partner integration domain, a country-specific TLD, an internal admin panel, a webhook receiver behind a proxy. No automation has ever renewed it; a person did, once, and then changed jobs. Manually issued certs are heavily overrepresented in expiry incidents relative to how few of them exist.
6. Reminders Sent to the Void
CA reminder emails go to whoever created the certificate — frequently a departed employee, a defunct distribution list, or an agency no longer under contract. And the industry is retiring reminders anyway: Let's Encrypt, which issues the majority of certificates on the web, ended its expiration notification emails in 2025 and explicitly told users to rely on monitoring instead. An email that might reach the right inbox is not a control.
7. The Infrastructure Moved On
You migrated from Heroku to Vercel, or from VMs to Kubernetes, eighteen months ago. Renewal for one forgotten domain still lives on the old platform — sometimes literally on a decommissioned box or an ex-employee's laptop. The migration checklist covered the app; nobody inventoried which certificates renewed where.
Shrinking Lifetimes Are Raising the Stakes
The maximum lifetime of publicly trusted certificates is shrinking on an industry-agreed schedule. Under the CA/Browser Forum's 2025 decision, certificates issued since March 2026 are capped at roughly 200 days, the cap drops to about 100 days in 2027, and it lands near 47 days by 2029. Let's Encrypt certificates were already 90 days, and even shorter-lived options are appearing. The direct consequence: renewal stops being an annual ceremony and becomes a continuous background process that must work every few weeks, forever. Every failure mode above gets more chances to occur per year, while the window between 'automation broke' and 'certificate expired' compresses. Manual renewal as a fallback strategy stops being merely tedious and becomes operationally impossible at fleet scale — which makes detecting broken automation early the whole game.
The One Detection Strategy That Covers All Seven
Notice what the seven failure modes have in common: in every single one, the certificate actually being served to the public is approaching expiry without being replaced. That shared symptom is the detection point. An external monitor that performs a real TLS handshake against each endpoint, reads the served certificate's notAfter date, and alerts on a countdown — 30, 14, and 7 days out is FourSight's default ladder — catches all seven modes with one mechanism, without needing to know anything about your renewal tooling. It doesn't matter whether the cause was a dead timer, a blocked challenge, or an undeployed renewal: if the cert your users receive is 29 days from expiry, someone gets told, while there's still time to debug calmly. Pair the countdown with chain validation and host-mismatch detection and you also catch the certificate problems that aren't about expiry at all.