You know what is fun? Getting paged at 3 in the morning because your SSL certificate expired and now every browser shows a giant red warning page where your homepage used to be. Customer support is on fire. Your mobile app is hard down because it pinned that exact cert. APIs are returning TLS handshake errors. Twitter is asking what happened.
You forgot to renew. Or worse, the auto renewal failed silently three weeks ago and nobody saw the alert email because it went to a shared inbox nobody checks anymore.
This story plays out somewhere on the internet basically every day. Big companies have done it. Cisco did it. Microsoft Teams did it. LinkedIn did it. Equifax did it (which somehow caused them to miss a different security breach for an extra two months because their monitoring was offline). Spotify, Pokemon Go, Starlink, all of them.
The only difference between those companies and yours is that those outages made the news. Yours probably will not. But they will still ruin your week.
Here is what SSL expiration actually is, why it gets shorter every year, what breaks when it happens, and how to stop the 3 AM page from ever showing up.
Why Certificates Expire in the First Place
Every SSL certificate has a notBefore and a notAfter field. Browsers and TLS libraries check both. If today is before notBefore (because someone issued the cert with a future start date) or after notAfter, the cert is rejected. No connection.
Why expire them at all? Why not just issue a cert and let it work forever?
A few reasons, all reasonable.
Key rotation. A long lived private key has a longer window for compromise. If your key gets stolen and you do not realize it, every year of validity is another year an attacker can impersonate your site. Forcing renewal forces fresh keys.
Algorithm aging. Cryptography evolves. Algorithms that were considered secure in 2010 are weak today. SHA-1 was deprecated. TLS 1.0 was deprecated. By forcing certs to expire, the ecosystem can move forward without leaving long lived weak certs in circulation.
Revocation as fallback. When a cert is compromised or misissued, it can be revoked. But revocation lists (CRLs and OCSP) are unreliable. Browsers cache revocation data, sometimes ignore it, sometimes the OCSP responder is down. Expiration is the universal fallback. Even if revocation never propagates, the cert eventually dies anyway.
Compliance. CA/Browser Forum baseline requirements set maximum validity. Certificate authorities must reissue periodically to confirm the customer still owns the domain.
The Lifetime Has Been Shrinking
For decades, you could buy a cert valid for 5 or even 10 years. That ended in 2011 when the CA/B Forum capped validity at 60 months. In 2018 it was cut to 825 days. In 2020, Apple unilaterally announced Safari would only trust certs with 398 day max validity. Google and Mozilla followed within months. The industry effectively settled at 398 days.
Now it is shrinking again. The CA/B Forum has approved a roadmap dropping max validity in stages:
- March 2026: 200 days max
- March 2027: 100 days max
- March 2029: 47 days max
This is not optional. Major browsers will reject certs with longer validity periods. By 2029 your cert will expire roughly every six and a half weeks. If you renew manually, you will spend the rest of your career renewing certificates.
The motivation is straightforward. Shorter lifetimes mean faster algorithm migration, smaller compromise windows, less reliance on flaky revocation infrastructure. Let's Encrypt has been issuing 90 day certs since 2015 and the world has not ended. The industry decided that scale works for everyone, not just Let's Encrypt users.
The implication for you is that automation is now mandatory. If you have not automated cert renewal yet, the clock is running. By 2027 you will not be able to afford manual renewals. You will forget. Everyone forgets.
What Actually Breaks When a Cert Expires
This is the fun part. The damage is way more than just a browser warning.
Web traffic dies. Every modern browser shows a giant scary red page. Chrome, Firefox, Safari, Edge. Users see "Your connection is not private" or worse. Most click away immediately. Bounce rate spikes to nearly 100% on the affected domain.
HSTS makes it worse. If you set Strict-Transport-Security on your site, browsers refuse to connect over HTTP after seeing it once. Once your HTTPS cert expires, those users cannot even fall back to HTTP. They are completely locked out until you fix the cert. The very header that protects you from downgrade attacks now blocks your own users.
APIs return TLS errors. Every server-to-server connection using HTTPS hits the same expiration. Your microservices fail their TLS handshake to each other. Webhooks from external services start returning timeouts. Payment processor callbacks fail. Cron jobs that hit your API silently log errors. The whole machine grinds.
Mobile apps crash. This is the worst one. If your mobile app uses certificate pinning (most do, for security), the app has the cert hash baked into the binary. When the cert expires, even the new cert does not match the pinned hash. The app cannot connect to your backend. Users see "connection failed" forever, or sometimes the app crashes outright. The fix requires shipping a new app version, which takes hours to days for App Store review.
Email servers stop sending. SMTP over TLS uses certs too. If the cert on your mail server expires, outbound email starts bouncing. Customer support emails do not go out. Magic link logins fail. Password resets fail. Order confirmations fail.
Internal services die. Wi-Fi networks using EAP-TLS authentication. VPN endpoints. Database connections that require TLS. Internal admin panels. All of them check certs. All of them fail when the cert expires.
This is why "we forgot to renew" outages are so painful. It is not just one domain going dark. It is a cascade through everything that touches that cert.
Real World Outages That Made The News
These are the ones I remember.
LinkedIn, 2017. linkedin.com cert expired. Site down for hours. The cert had been bound to an old auto renewal system that nobody had updated when ownership of the domain moved between teams. Classic.
Microsoft Teams, February 2020. A cert in the Teams authentication chain expired. Millions of users could not log in. Outage lasted three hours. Microsoft had to manually push a new cert during what became one of their most embarrassing outages of the year.
Cisco WebEx, multiple times. WebEx has had at least two major outages from expired certs in the last 5 years. Same pattern: enterprise software, complex cert chain, automation gap somewhere.
Equifax, 2017. Their cert expired silently inside their network monitoring infrastructure. The expired cert disabled the device that should have detected the breach. They missed signs of the breach for 76 extra days. The breach itself was ultimately a different issue, but the missed detection window directly traced back to a cert nobody noticed had died.
Starlink, 2022. Cert expired on a critical authentication server. Service outage hit thousands of users globally. Took 6 hours to fully recover.
Pokemon Go, 2021. Cert expired on a backend service. Players got stuck on loading screens for hours.
You can probably find more on Wikipedia's "list of internet outages caused by expired SSL certificates" page. There is enough material for a whole article on its own.
Tools for Automated Renewal
The fix is automation. Here are the tools that actually work.
Let's Encrypt + Certbot. Free, ACME protocol, runs on basically every server. Default 90 day certs renew automatically every 60 days via cron or systemd timer. The vast majority of small to medium sites use this and have for almost a decade. Certbot has been ported to every Linux distro, plus Windows and macOS. Setup is minimal:
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yoursite.com
That issues a cert and configures Nginx to use it. Renewal runs via systemd timer or cron. You almost never have to touch it again.
AWS Certificate Manager (ACM). If you use AWS, ACM is the path. Free certs that auto renew, integrated with ALB, CloudFront, API Gateway. The cert lives in AWS, never on a disk you manage. Just point your service at the ACM ARN.
Cloudflare. If your traffic flows through Cloudflare, they manage the edge cert automatically. The cert renews itself, you do not see it, you do not touch it. Origin certs (between Cloudflare and your server) are issued for 15 years by default and you can rotate them manually whenever.
Caddy. The web server that just ships with automatic HTTPS via Let's Encrypt built in. Set up your domain, Caddy gets the cert. Done. No certbot, no cron, no manual config. Worth considering for new projects.
Vercel, Netlify, Fly, Railway. All managed platforms handle cert issuance and renewal for you. You point a domain at them, they handle TLS. No work on your side. This is the easiest option if you are running on these platforms.
ACME for everything else. ACME is the protocol Let's Encrypt uses, but other CAs implement it now too. ZeroSSL, Buypass, Google Trust Services. If you need redundancy or want a non-Let's-Encrypt issuer, you can use ACME clients like acme.sh or Lego.
When Automation Fails (And It Will)
Even with automation, things break. These are the failure modes I have seen multiple times.
DNS validation breaks. ACME requires you to prove control of the domain. Most setups use HTTP-01 (a file at a known URL) or DNS-01 (a TXT record). If your DNS API breaks, your DNS provider rate limits you, or your DNS records get out of sync, validation fails. The auto renewal fails silently. The cert expires.
Rate limits. Let's Encrypt enforces rate limits to prevent abuse. The main one is 50 certs per registered domain per week. If you have hundreds of subdomains and your automation re-issues all of them at once after a config change, you can hit the limit and renewals start failing. The rate limit window is 7 days, so this can cascade if you do not notice.
Renewal alerts going to dead inboxes. Let's Encrypt sends warning emails 20 days, 10 days, and 1 day before expiration if you registered with an email. If those emails go to a shared inbox nobody monitors, or to the personal email of a developer who left two years ago, the warnings are useless. Always register renewal alerts with a monitored, persistent email address.
OCSP stapling failures. Some servers use OCSP stapling, where the server includes a fresh OCSP response with each connection. If the OCSP responder for your CA is slow or down, your stapling can break. Most browsers tolerate this, some do not. The cert is technically still valid but connections might fail in some clients.
Manual cert in an automated environment. Someone uploads a manual cert "just for now" because automation was being weird. They forget. The manual cert expires later, when nobody remembers it exists. Always prefer automation, even when it requires extra config work.
Container restarts losing renewal state. If your cert renewal data lives inside a container that gets recreated, the renewal state can vanish. Some setups need to mount the cert directory as a volume so it persists across deploys.
A Sane Monitoring Strategy
Even with automation, monitor your certs. Trust nothing. Verify everything.
Three tier alerting. Send a low priority alert at 30 days before expiration. Medium priority at 14 days. Page somebody at 7 days and again at 1 day. The 30 day alert catches "automation is broken but I still have time to fix it manually." The 1 day alert catches "everything is broken, I need to fix this right now."
External monitoring. Have an external service check your certs from outside your infrastructure. If your monitoring runs on the same cluster as the thing being monitored, it might fail at the same time. UptimeRobot, Pingdom, BetterStack, even custom scripts running on a different cloud provider all work.
Check every domain. Not just the main site. Every subdomain. Every internal service that uses TLS. Every API endpoint. Every microservice. Every Wi-Fi RADIUS server. The expiration that bites you is always one you did not know about.
Use OpenSSL to verify. Quick check from any machine:
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
That prints the notBefore and notAfter dates. Plug it into a script, run it via cron, alert if notAfter is within 7 days. Cheap and reliable.
Use a dedicated checker. Our free SSL checker at whatismyip.technology/tools/ssl-checker runs the same check via Certificate Transparency logs. It returns issuer, validity dates, days remaining, expired status, and SAN list for any domain. No signup. Bookmark it.
Certificate Transparency
Every cert issued by a public CA gets logged to a public Certificate Transparency (CT) log. This was created after a few CAs misissued certs in the early 2010s. Now every cert is publicly logged within hours of issuance.
This has two practical uses for you.
Audit what certs exist for your domains. Even if you did not issue them. If a CA misissued a cert for your domain (or an attacker tricked one into doing so), CT logs would show it. Tools like crt.sh let you search by domain.
Find every cert you have. If your team is decentralized, you might have certs you forgot about. Check CT logs to find every cert ever issued for your top level domain. Some of them will be for services you forgot existed but still need to monitor.
The SSL checker tool we built uses crt.sh under the hood to pull this data quickly.
Wildcard, SAN, and Single Domain Certs
Different cert types, different expiration handling.
Single domain cert. Just one hostname. Easy. One cert, one renewal cycle.
SAN cert (Subject Alternative Name). Multiple hostnames in one cert. Common for web setups where example.com and www.example.com and api.example.com all share a cert. When the cert renews, all the names update at once. Convenient.
Wildcard cert (*.example.com). Covers any subdomain at one level. Useful if you have many subdomains. The catch: wildcard certs require DNS-01 ACME validation, which means your DNS provider must have an API that the ACME client can update. Some DNS providers do not support this well, which can break automation.
Multi-level wildcards do not exist in the standard. *.*.example.com is not valid. If you need that pattern, you need separate certs per level.
Renewal complexity. Wildcards expiring while you have unknown subdomains using them is a special kind of pain. Always know what is using each cert. If you are managing wildcards, document which services use them and verify those services pick up the renewed cert.
A Simple Action Plan
If you are reading this and realizing you might be one renewal away from disaster:
- List every domain you own. Pull from your registrar. Yes, the ones you forgot about too.
- Run the SSL checker on each one. Note the expiration date.
- Find the ones expiring in less than 30 days. Renew now.
- Check what is automated. If it is not automated, automate it.
- Set up monitoring with 30/14/7/1 day alerts. Send to a real inbox.
- Document which services use which certs. When in doubt, draw it on a napkin and put it in a wiki.
- Test renewal in staging. Force a renewal cycle and verify nothing breaks.
That covers 99% of the cases that lead to outages. The 1% remaining is creative new failure modes nobody has invented yet.
How This Connects to Everything Else
Cert expiration is one piece of the larger TLS picture. The cert is just the proof of identity. The actual TLS handshake involves a lot more. If you are debugging connection issues, the cert is one place to look but not the only one. Wrong cipher suites, missing intermediate certificates, OCSP failures, and SNI mismatches all cause connection problems that look like cert problems.
For a quick diagnostic when something breaks, our SSL checker is the fastest path. For deeper debugging, openssl s_client with verbose output is the canonical tool.
If the connection is failing for reasons beyond the cert, take a step back and check whether your IP is the issue. A blacklisted IP can cause some clients to refuse connections regardless of cert validity. Our IP blacklist check walks through how to verify that. And HTTP headers can reveal a lot about what the server is actually returning if you suspect a misconfiguration.
The Big Picture
Certs expire. They always have. The expiration window is shrinking and will shrink more. Manual renewal will become impossible at scale within a few years.
The fix is automation, monitoring, and ownership. Every cert needs a system that renews it, alerts that fire when renewal fails, and a person who is responsible for the cert when alerts fire.
Companies that have outages from expired certs almost always have an automation gap somewhere. Either renewal was never set up, or it broke silently, or it was working but the alerts went to a dead inbox.
Do not be that company. Set it up once. Verify the alerts work. Walk away. Then check back every six months to make sure nothing rotted.
The 3 AM page is optional. You just have to choose not to subscribe to it.