SSL Certificate Expiration: The Other Expiry Date You're Probably Forgetting
You've got domain monitoring set up. Auto-renewal enabled. Alerts configured. Your domain is safe.
Then your SSL certificate expires and your entire site shows security warnings.
SSL certificate expiration is the other deadline that causes outages. It's more common than domain expiration, happens faster, and can be just as damaging to your business.
Why SSL Expiration Matters
Modern Browsers Don't Forgive
When your certificate expires, browsers don't politely inform users of a minor technical issue. Chrome displays "Your connection is not private" with a full-page warning. Firefox shows "Warning: Potential Security Risk Ahead" with ominous red indicators. Safari warns "This Connection is Not Private" and makes proceeding extremely difficult.
These warnings aren't advisory - they're blockers. Modern browsers have made bypassing certificate warnings so difficult that most users simply leave. A typical user seeing these warnings concludes your site is compromised or your business is untrustworthy. They're not going to click through multiple "Advanced" options to reach your content.
Search Engines Penalize
Google made HTTPS a ranking factor years ago, and an expired certificate means search crawlers can't access your site properly. Your rankings drop. Your organic traffic disappears. The SEO value you've built over months or years degrades because of a missed expiration date.
APIs Break Silently
API certificate expiration is particularly insidious. When your customer-facing website has an expired certificate, users see warnings and complain. When your API certificate expires, clients receive SSL errors, integrations fail, and automated systems stop working - but nobody visits your API endpoint to see an error message.
You discover the problem when customers start complaining that their integrations with your service have stopped working. By then, you've been breaking their products for hours or days.
E-commerce Impact
For any site handling payments, certificate expiration creates immediate compliance and business problems. PCI compliance requires valid certificates. Payment processors may reject requests from expired endpoints. Customer trust evaporates the moment they see a security warning on your checkout page. Cart abandonment spikes because nobody enters payment information on a site their browser says isn't secure.
Why SSL Expiration Keeps Happening
Shorter Certificate Lifespans
The industry has progressively shortened maximum certificate validity. In 2015, you could get certificates valid for five years. By 2018, the maximum dropped to two years. Since 2020, the maximum is just thirteen months. Let's Encrypt certificates, now the most common type, are valid for only ninety days.
More frequent expiration means more opportunities to miss renewal. What used to be an annual event is now a quarterly one for many organizations.
Auto-Renewal Isn't Universal
Unlike domain registration, automatic certificate renewal isn't a default everywhere. Paid certificates from traditional certificate authorities often require manual renewal. Some CDN configurations need manual intervention. Internal certificates rarely auto-renew at all. Wildcard certificates may have different processes than standard certificates.
Assuming auto-renewal works because your domain auto-renews is a common mistake that leads to outages.
Multiple Certificates, Multiple Processes
Organizations accumulate certificates the way they accumulate domains - organically and without central management. Different certificates for different domains, certificates from different providers, different renewal processes for each, and no unified tracking across the portfolio. The certificate that expires is usually the one nobody was watching.
The "Someone Else Handles It" Problem
Ownership ambiguity kills certificate management. DevOps thinks the infrastructure team manages certificates. Infrastructure thinks DevOps handles it. The contractor who originally set everything up left two years ago, and nobody documented the renewal process. No one actually owns certificate management, so no one ensures it happens.
Let's Encrypt Assumptions
"We use Let's Encrypt, it auto-renews." This is usually true, but the devil is in the details. Certbot needs to actually run, which means the cron job or systemd timer can't have silently failed. The server needs to be accessible for the ACME challenge, which changes when you modify firewall rules or proxy configurations. Container rebuilds may break renewal hooks. Configuration drift breaks things that worked six months ago.
SSL vs Domain Expiration: Key Differences
The two expiration types behave differently in ways that make SSL more dangerous. Domain expiration typically gives you sixty or more days of warning, while SSL warnings may never arrive if renewal automation is supposed to handle it. Domain expiration comes with a grace period of thirty to forty-five days where you can still recover; SSL certificates have zero grace period - one day they're valid, the next they're expired.
When a domain expires, users see "site not found" messages. When SSL expires, they see frightening security warnings. Domain recovery takes hours to days; SSL certificate replacement takes minutes to hours once you realize the problem. But the biggest difference is frequency: domains typically expire annually while SSL certificates can expire every ninety days.
SSL expiration happens more often and has no grace period. That's why it catches more organizations off guard.
Setting Up SSL Monitoring
Monitor certificate validity across all your properties. Track days until expiration, current certificate details, and chain validity. Don't just monitor your main website - include all API endpoints, subdomains, and internal services. Certificate chains matter too, since intermediate certificate issues can cause failures even when your leaf certificate is valid.
Alert thresholds should differ based on your renewal process. For automated renewal systems like Let's Encrypt, if a certificate hasn't renewed by fourteen days before expiration, that's informational because it should have renewed by now. At seven days, it becomes a warning because renewal is likely failing. At three days, it's critical and needs immediate attention.
For manual renewal processes, start much earlier. At sixty days, begin the renewal process. By thirty days, renewal should be complete. At fourteen days, something is urgently wrong. At seven days, it's an all-hands emergency.
SSL alerts should be treated like downtime alerts because certificate expiration causes downtime. Email the team for early warnings. Send Slack or Teams notifications for medium urgency. Use SMS for critical thresholds. Page on-call for emergencies.
Building SSL Resilience
Start by inventorying all certificates across your organization. Document every certificate including the domain or domains it covers, the issuing certificate authority, the expiration date, the renewal process (automated or manual), and the person or team responsible for renewal.
Standardize on automated renewal wherever possible. Use Let's Encrypt with properly configured automation. Use CDN-managed certificates from providers like Cloudflare or AWS that handle renewal automatically. For paid certificates, automate renewal where the provider supports it.
Implement monitoring for every certificate. External monitoring validates what users actually see when they connect. Internal monitoring catches misconfigurations before they affect production. Alert through multiple channels so warnings can't be missed.
Create renewal runbooks for certificates that need manual intervention. Document the step-by-step renewal process, contact information for the certificate authority, where to install the new certificate, how to verify installation worked, and how to roll back if something goes wrong.
Test your monitoring regularly. Verify that alerts actually fire at the correct thresholds. Confirm alerts reach the right people. Ensure the team knows how to respond when alerts arrive.
Special Considerations
Wildcard Certificates
Wildcard certificates cover multiple subdomains with a single certificate. This simplifies management significantly, but creates a single point of failure. When that one certificate expires, every subdomain using it shows warnings simultaneously. Monitor wildcard certificates especially closely, and consider redundant certificates for critical subdomains that can't afford any downtime.
Internal and Private Certificates
Internal certificates are often forgotten because they're not publicly accessible. No external monitoring catches their expiration. The attitude of "it's just internal" leads to lax management. But internal outages disrupt work just as much as external ones, affecting employee productivity rather than customer experience. Monitor internal certificates with the same rigor as public ones.
Certificate Pinning
If you've implemented certificate pinning - where applications reject any certificate that doesn't match a specific fingerprint - expired certificates cause complete breakage with no browser override possible. Emergency certificate rotation becomes complex because clients pinned to the old certificate reject the new one. If you use pinning, pin to an intermediate certificate authority rather than your leaf certificate, and have a rotation process ready before you need it.
Load Balancer Certificates
Certificates on load balancers may not be visible to standard external monitoring that checks only origin servers. They require explicit endpoint checks that test the actual load balancer connection. The update process differs from server certificates and may require different procedures and different personnel.
CDN Certificates
CDN-managed certificates are usually automatic, but verification matters. Confirm auto-renewal is actually enabled in your configuration. Check that all custom domains are covered by the CDN's certificate management. Monitor the CDN endpoint, not just your origin server, since that's what users actually connect to.
Integration with Domain Monitoring
The most reliable approach monitors domains and SSL certificates together. Domain expiration, SSL certificate expiration, DNS configuration, and uptime monitoring all belong in the same dashboard with unified alerting.
Integration matters because it's one fewer tool to check and maintain. You get a unified view of domain health across all dimensions. Correlated alerts help diagnose problems - a DNS issue might explain why certificate renewal is failing. You have a single source of truth for your domain portfolio's status.
Recovery from SSL Expiration
When a certificate expires, act immediately. Verify the expiration by checking certificate details directly, then renew or replace the certificate as quickly as possible. Install the new certificate and verify the site works from multiple locations and browsers.
For Let's Encrypt certificates, force renewal with certbot using the --force-renewal flag. Verify the new certificate with certbot certificates. Reload your web server to pick up the new certificate.
For manual certificates, the process involves generating a new certificate signing request if required, completing the certificate authority's verification process, downloading the new certificate, installing it on all relevant servers, reloading or restarting affected services, and verifying from multiple locations that everything works.
After recovery, document what happened, fix monitoring and alerting gaps that allowed the expiration to go unnoticed, implement preventive measures, and update runbooks with lessons learned.
The Bottom Line
SSL expiration is the silent sibling of domain expiration. Both cause outages. Both are preventable. Both get forgotten.
If you're monitoring domain expiration, add SSL monitoring. Same philosophy, same urgency, same automation. The few minutes to set up monitoring saves hours of emergency response.
Your certificate expires in ninety days. Do you know when?
Recommended Reading
- Free SSL Certificate Monitoring - Set up SSL monitoring
- Domain Expiration: The Silent Killer - Why expiration monitoring matters
- Building a Domain Health Checklist - Complete monitoring setup
Morten Pradsgaard is the founder of exit1.dev — the free uptime monitor for people who actually ship. He writes no-bullshit guides on monitoring, reliability, and building software that doesn't crumble under pressure.