Error guide

SSL certificate expired

The certificate's validity period has passed, so every client refuses the connection.

An expired certificate means the notAfter date in the certificate the server presents has passed. Clients validate that date before anything else, so the connection is refused during the handshake — no request is ever sent, and nothing in your application logs will record the visit.

The failure is total and simultaneous. Every browser shows an interstitial that most visitors will not click through, every API client fails, every integration stops. Unlike most outages it affects one hundred percent of traffic from the exact second of expiry.

It is also the most preventable outage there is, since the date was knowable from the moment the certificate was issued. Which is why the interesting question is never what expired but why the renewal did not happen — automation exists nearly everywhere now, and these outages still happen because the automation stopped quietly.

Common causes

  • A renewal job that stopped running after a server rebuild, a cron change or a package upgrade.
  • A certificate renewed on disk but never reloaded by the running process.
  • An ACME challenge failing because of a redirect rule, a firewall change or a DNS change.
  • A certificate on a load balancer, CDN or mail server that no automation ever covered.
  • A manually issued certificate whose renewal depended on someone remembering.
  • Renewal succeeding for one hostname while another name on the same service was missed.

How to diagnose it

  1. Read the certificate the server is actually serving, with openssl s_client, rather than the one you believe is installed.
  2. Check whether a newer certificate exists on disk — if it does, the process never reloaded and a reload is the whole fix.
  3. Check the renewal job's logs and its last successful run.
  4. Try a renewal manually and read the error: a failed ACME challenge names its reason.
  5. Check every hostname and every endpoint separately; a service can serve a valid certificate on one name and an expired one on another.

Whose fault is it? The server's side

Server-side and entirely preventable. The client is behaving correctly by refusing; an expired certificate is exactly the condition validation exists to catch.

What monitoring sees

This is the failure that certificate monitoring exists for, and it is worth having separately from an uptime check: an uptime monitor tells you the site is down after expiry, while an SSL Certificate monitor with an Expires In Days criterion tells you in advance that it is going to be. Without that criterion the monitor reads the days left but does not alert on them, so add one when you create it. Uptimely's SSL Certificate monitor reads the certificate from the live handshake, so it reports on what the server is actually serving rather than on what is on disk.

Product feature

Related error guides

Terms used on this page

Questions

How much warning should a certificate alert give?

Use more than one horizon: thirty days as a ticket, seven days as a real alert, and one day as an incident. A failed renewal usually needs a person, and the last day is not when you want to discover that.

Why did my auto-renewing certificate still expire?

Usually the renewal ran and nothing reloaded it, or the job stopped after a rebuild, or the ACME challenge started failing. Checking the certificate served by the live handshake, rather than the file on disk, catches all three.

One of the Uptimely HTTP and network error guides, written for the person who operates the server rather than the one refreshing the page. Something here read wrong to you? Email support@getuptimely.com.