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

When a TLS certificate expires, clients reject the connection immediately — browsers show a full-page warning, APIs fail the handshake, and the service is down. There is no grace period. Here is exactly what breaks, and how to stop it.

The moment of expiry

A certificate doesn't degrade — it fails all at once. At the exact second it passes notAfter, every client that validates it starts refusing the connection. RFC 5280 What that looks like depends on who's connecting:

• Browsers throw a full-page interstitial — "Your connection is not private" (NET::ERR_CERT_DATE_INVALID in Chrome). Most visitors never click past it.
• APIs and backend integrations fail the TLS handshake outright. There's no screen to click through — the request just errors, so dependent services and webhooks break silently.
• Mobile clients reject the expired certificate on normal validation; certificate pinning adds further failure modes, but pinning isn't the reason expiry is rejected.
• Automated jobs — cron tasks, CI/CD pipelines, machine-to-machine calls — start failing on their next run, often where no human is watching.

There is no grace period

How to check when a certificate expires

For a single host, openssl gives you the exact expiry in one line:

echo | openssl s_client -connect example.com:443 2>/dev/null \
    | openssl x509 -noout -dates
# notBefore=... / notAfter=...  ← the second value is when it dies

That works for a certificate you already know about. The one that causes the outage is almost always the one you don't — which is why checking by hand doesn't scale.

How to prevent expiry outages

Reliable certificate operations come down to three habits, in order:

• Discover everything. You can't renew what you can't see. Maintain a continuous inventory across every domain, cloud, and internal network — not a one-time spreadsheet.
• Monitor with lead time. Alert on expiry weeks ahead, routed to an owner who can act — not a shared inbox nobody reads.
• Automate renewal. Remove the human from the loop with ACME-based auto-renewal, and verify the new certificate is actually deployed and serving.

Expiry-prevention checklist

• Every certificate is in a continuously-updated inventory (public, cloud, and internal)
• Expiry alerts fire at 30+ days out to a named owner, not a shared mailbox
• Renewal is automated (ACME) wherever the endpoint supports it
• Post-renewal deployment is verified — the served certificate matches the issued one
• A dead-man check catches a silent renewal-job failure before it becomes downtime

In the 47-day era, the window between "still fine" and "outage" is measured in days. Discovery and monitoring buy you the lead time; automation is what actually keeps you online.

Frequently asked