On September 30, 2024, Let's Encrypt's root certificate expired. Within hours, thousands of websites became inaccessible to older Android devices. No DNS failure. No server outage. Just a certificate that stopped being trusted. This wasn't a freak incident—it was the latest in a series of preventable collapses that keep catching supposedly sophisticated companies off guard. The embarrassing part: SSL certificate monitoring is trivial to automate, yet somehow remains one of the most common causes of unexpected downtime reported to us at WebsiteDown.
Why Companies Miss Expiration Dates on Their Own Certificates
The obvious answer—forgot to renew—is rarely the real one. Most outages happen because the certificate lives in infrastructure nobody owns anymore. A service might have been migrated to a different platform, but the old certificate renewal process still lives in an automation system that nobody updated. The person who set up the original renewal task left the company three years ago. The certificate is stored in a legacy HSM that requires manual intervention. Or the renewal webhook points to a service that no longer exists. We've seen production certificates expire while automated renewal systems silently failed, sending alerts to an email address that gets 400 messages a day.
The Surprising Thing About Intermediate Certificates
Here's what most people miss: you can have a valid end-entity certificate and still have browsers reject your connection if your intermediate certificate expired. This is technically possible and happens more often than you'd think. The chain of trust requires every certificate in the chain to be valid. An expired intermediate certificate sitting on your server won't cause an obvious error during testing—it might work fine for clients that already have the intermediate cached, but fail for anyone hitting your service fresh. We've documented cases where a company's certificate appeared valid according to standard tools, but was silently failing for 15% of their user base because of an intermediate they didn't know they needed to renew.
Why Monitoring Tools Themselves Are Part of the Problem
Most certificate monitoring services check if a certificate is valid *right now*. They don't check if your renewal automation is actually working. A certificate might pass every check until 48 hours before expiration, when suddenly nothing can be done. The real question—does your system have a valid, renewed certificate staged and ready to deploy?—goes unanswered. Better monitoring should validate that new certificates are being generated automatically and staged in the right places before the old one expires. Even better: it should test that your deployment automation can actually install the new certificate without manual intervention.
The Asymmetric Cost of This Problem
A certificate expiration outage is brutal because it's completely binary. Your service doesn't degrade—it simply stops working for all new connections. Unlike a database that's slow, or a server that's flaky, an expired certificate means clients get a hard rejection. Browser warnings. Mobile app connection failures. API clients get SSL verification errors. There's no graceful degradation, no 'service partially available.' The downtime is also visible to monitoring tools immediately, which means your incident response clock starts the moment browsers start hitting your service. And unlike most infrastructure problems, you can't debug this live—you have to fix it offline and redeploy.
What You Should Do Monday Morning
Audit every certificate your company uses right now. Not just production—staging, internal APIs, load balancers, CDN configurations, everything. For each one, document: where it's stored, how it's renewed, who owns the renewal process, and where renewal alerts go. Then set up monitoring that doesn't just check expiration dates—it validates that a new certificate has been generated and staged at least 30 days before the old one expires. Use a tool that can test your actual deployment pipeline. Finally, set calendar reminders for 60 days before every certificate expires, owned by someone other than the person who maintains the service. The person who originally set it up isn't reliable. Neither is email.