SSL Certificate Expiry: Why It Happens, What It Costs, and How to Prevent It

Your SSL certificate has an expiry date. When that date passes, every visitor to your site sees a full-page browser warning — a red shield, the words "Your connection is not private", and options to go back or proceed at their own risk. Most users choose to go back.

The frustrating part: this is entirely preventable. SSL expiry is not a complex technical failure — it is a calendar problem. Yet it keeps happening to teams of all sizes, including at some of the world's largest technology companies.

What Exactly Happens When an SSL Certificate Expires

When a browser connects to your website, it checks the SSL certificate presented by your server against four criteria: it must be issued by a trusted Certificate Authority, it must match your domain, it must not be revoked, and it must not be expired. If any check fails, the browser blocks the connection.

• Chrome shows a red "Not Secure" warning with ERR_CERT_DATE_INVALID — no way to proceed without manually bypassing.
• Safari shows "This Connection Is Not Private" and prevents page load entirely by default.
• Firefox shows "Warning: Potential Security Risk Ahead" and requires an explicit advanced override.
• Mobile browsers on Android and iOS show similar blocking warnings.
• Google Search Console may flag your site for security issues, which can negatively impact rankings.
• Automated clients (mobile apps, APIs, webhooks) receive TLS handshake errors and stop functioning completely.

Why SSL Certificates Still Expire in 2026

It is tempting to think this is a solved problem — just enable auto-renewal and move on. The reality is that auto-renewal has many ways to fail silently, and the failure only becomes visible when the certificate actually expires.

1. 1Team rotation — the engineer who set up the certificate left the company. Nobody knows the renewal credentials or which service handles it.
2. 2Email goes to a dead inbox — renewal reminders from the CA go to a shared alias nobody monitors, or to a former employee's email address.
3. 3DNS validation failure — Let's Encrypt and other CAs validate domain ownership via DNS TXT records. If your DNS provider changes, those records disappear.
4. 4Payment method expired — certificate renewals from commercial CAs fail silently when the credit card on file is outdated.
5. 5Infrastructure migration — the server was migrated to a new host, but the auto-renewal cron job or Certbot config was not copied over.
6. 6Wildcard certificate complexity — wildcards must be renewed manually with DNS-01 challenge in many configurations; there is no simple HTTP-01 auto-renewal path.
7. 7Short certificate lifetimes — since 2023, most certificates are issued for 90 days (Let's Encrypt) or 1 year (commercial). More renewals = more chances for failure.

Real-World SSL Expiry Incidents

SSL expiry is not just a small-business problem. Here are documented incidents from major technology companies:

• LinkedIn (2014) — a wildcard certificate for *.linkedin.com expired, affecting login and core features for thousands of users.
• Spotify (2016) — the Spotify Web Player stopped working due to an expired certificate for a core API endpoint.
• Microsoft Azure (2013, 2021) — Azure DevOps experienced an outage caused by an expired certificate affecting storage services.
• Ericsson (2018) — an expired certificate in their network software caused widespread outage for UK mobile networks including O2, affecting 32 million users for over 24 hours.
• Equifax (2017) — buried in the details of their famous data breach: an expired SSL certificate on an internal monitoring tool meant the breach went undetected for 76 days.

Auto-Renewal Pitfalls to Watch For

If you use Let's Encrypt with Certbot (the most common free SSL setup), here are the specific failure modes to check:

• HTTP-01 challenge with a reverse proxy — if your nginx or Caddy config does not correctly route /.well-known/acme-challenge/ requests to Certbot, renewal silently fails.
• Certbot running as the wrong user — Certbot needs to write to /etc/letsencrypt/ and restart your web server. Permission errors cause silent failures.
• The renewal cron job is present but not running — check with `sudo systemctl status certbot.timer` or `crontab -l`. Server restarts can sometimes drop cron schedules.
• Certificates renewed but not loaded — Certbot renews the cert but your nginx/Apache/Node server keeps serving the old one until restarted. The reload hook must be configured.
• Rate limits — Let's Encrypt limits you to 5 duplicate certificate requests per week. A misconfigured renewal loop can burn through this limit and leave you unable to renew.

How to Monitor SSL Certificates Properly

Auto-renewal is necessary but not sufficient. External SSL monitoring is your safety net — it checks the actual certificate your server is presenting to the world, independent of your renewal configuration.

A proper SSL monitor should:

1. 1Check the certificate daily — not just at renewal time.
2. 2Alert at 30 days before expiry — giving you time to investigate a broken renewal process.
3. 3Alert again at 14 days — time to escalate and manually intervene if auto-renewal has not fired.
4. 4Alert at 7 days and 3 days — final warnings before your site starts showing browser errors.
5. 5Check that the certificate chain is valid — a misconfigured intermediate cert causes browser errors even on non-expired certs.
6. 6Verify the domain name matches — a certificate issued for www.example.com does not cover example.com (without a SAN), which causes errors on the bare domain.
7. 7Monitor all your subdomains separately — api.example.com, dashboard.example.com, and app.example.com each have their own certificate.

Wildcard and Multi-Domain Certificates

Wildcard certificates (*.example.com) cover all subdomains with a single certificate — convenient but with unique renewal challenges:

• Wildcard certs cannot be renewed with HTTP-01 challenge — only DNS-01. This requires your DNS provider to have an API and a configured DNS plugin for Certbot.
• Commercial wildcard certs often require manual approval from a domain admin email. If that email is not monitored, the renewal stalls.
• A wildcard cert expiry takes down every subdomain simultaneously — a single failure has maximum blast radius.
• Multi-domain (SAN) certificates list all covered domains explicitly. Adding a new subdomain requires reissuing the entire certificate.
• Monitor the expiry date of the wildcard cert, not just one subdomain. The cert is shared — the expiry is the same for all covered domains.

SSL Health Checklist

Run through this list for every domain you operate:

• ☐ External SSL monitor active, with alerts at 30d / 14d / 7d / 3d before expiry.
• ☐ Renewal notifications go to a shared team inbox, not a personal email.
• ☐ Auto-renewal dry-run tested in the last 30 days.
• ☐ All subdomains monitored separately (especially api.*, dashboard.*, app.*).
• ☐ Certificate chain validated (not just the leaf certificate).
• ☐ Domain name coverage confirmed (bare domain AND www both covered).
• ☐ Payment method for commercial CAs is up to date.
• ☐ DNS-01 challenge credentials documented for wildcard certs.
• ☐ After every server migration: confirm Certbot or renewal config was carried over.