What Happens When an SSL Certificate Expires (and How to Prevent It)

An expired SSL certificate is one of the fastest ways to take your own website offline — and it happens to companies of every size, including ones with entire ops teams. Unlike a slow content problem, it's binary: the certificate is valid until a specific timestamp, and the moment it passes, browsers stop trusting your site and start actively warning people away.

Here's what actually happens, and how to make sure it never happens to you.

What visitors see the moment it expires

When a certificate expires, browsers don't quietly degrade — they throw up a full-page security warning that blocks the site:

• Chrome: "Your connection is not private" with NET::ERR_CERT_DATE_INVALID.
• Firefox: "Warning: Potential Security Risk Ahead" with SEC_ERROR_EXPIRED_CERTIFICATE.
• Safari: "This Connection Is Not Private."

To get through, a visitor has to click past scary-sounding "Advanced" and "proceed anyway" links that most people — correctly — won't click. For all practical purposes, your site is down, and worse, it looks unsafe rather than merely broken. That's a trust hit that outlasts the outage itself.

What breaks behind the scenes

The visible warning is only half of it. An expired certificate breaks anything that speaks HTTPS to your domain:

• APIs and integrations fail. Any client doing proper certificate validation — mobile apps, webhooks, partner integrations, payment callbacks — gets a TLS handshake failure and stops working. These failures are often silent until something downstream breaks.
• E-commerce and checkout halt. Payment flows refuse to run over an untrusted connection. Every minute of expiry is lost revenue.
• Email and other TLS services. If the same certificate covers mail or other services, those can fail too.
• SEO and reputation. Search crawlers hitting an untrusted site, and users bouncing off a security warning, both send the wrong signals.

The financial damage isn't hypothetical — there are well-documented cases of major services suffering multi-hour outages traced to a single lapsed certificate.

Why SSL certificates expire so often

Certificates are deliberately short-lived, and they're getting shorter:

• Let's Encrypt certificates last 90 days. They're designed to be renewed automatically every ~60 days.
• Paid certificates used to last a year or more, but the maximum lifetime has been steadily cut by the CA/Browser Forum. The industry is moving toward much shorter validity — eventually measured in weeks, not years.

Short lifetimes are good for security (a compromised key is only useful briefly), but they mean renewal is a constant, recurring event, not a once-a-year chore. More renewals means more chances to miss one.

Common ways a certificate slips through:

• Auto-renewal silently fails. A certbot cron job breaks after a server change, a port-80 validation gets blocked by a firewall rule, or a DNS validation record is removed. The renewal stops happening and nobody notices until the cert expires.
• A certificate no one is renewing. A cert was issued manually for a subdomain or an internal service, and the person who set it up left.
• The reminder went nowhere. The CA's expiry email went to a shared inbox or an address no one monitors.

How to check when your certificate expires

You don't need special tools. From any machine:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates

That prints notBefore and notAfter — the expiry is notAfter. In a browser, click the padlock in the address bar and view the certificate details to see the "Valid until" date.

Checking once is easy. The hard part is checking every certificate, on every domain and subdomain, continuously — because the one you forget is the one that takes you down.

How to prevent SSL expiry for good

1. Automate renewal — and then verify the automation. Use certbot, your host's managed certificates, or your CDN's automatic SSL. But automation isn't "set and forget": a renewal job that silently stopped working looks identical to one that's fine, right up until expiry. Confirm renewals are actually happening.

2. Monitor the live certificate, independently. The most reliable safeguard is to check the certificate that's actually being served — from outside your infrastructure — and alert well before it expires. This catches every failure mode at once: a broken cron job, a bad deploy that reverted a cert, a subdomain nobody remembered. If the served certificate is 14 days from expiring, you want to know today, not from a customer.

3. Cover every hostname. Don't just watch yourdomain.com. Watch www, api, app, mail, and any other subdomain with its own certificate. Each is a separate expiry date and a separate way to go down.

4. Give yourself lead time. A warning that fires the day of expiry is nearly useless. Alerts at 30, 14, and 7 days out give you room to fix the underlying automation calmly instead of scrambling during an outage.

This is exactly what DomainChest does for the SSL side: for every domain you add, it reads the live certificate being served and tracks its real expiry date, then emails you well in advance — alongside your domain registration dates, in one place. You don't have to trust that your renewal automation is healthy; you get told the moment the served certificate starts running out of runway.

The takeaway

An expired SSL certificate turns your site into a security warning, breaks your APIs, and stops your checkout — instantly, at a precise timestamp you could have seen coming. Certificates now expire every 90 days or less, so renewal is a recurring event that will eventually be missed if you rely on memory or on automation you never verify. Automate renewal, then independently monitor the certificate that's actually live, with enough lead time to fix problems before they become outages.