The only outage that arrives with a publication date

Every other outage is a surprise. A disk fills, a provider has a bad afternoon, an update breaks a plugin, a query starts locking a table. None of them announce themselves.

A certificate expiry is written down. The date is in the certificate, the certificate is public, and anyone can read it from anywhere at any time. It is the only failure in this trade where the incident has been scheduled, in advance, in a document you can fetch in one second.

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

What makes it worse than an equivalent outage

A 500 error is bad. An expired certificate is worse than a 500 for four reasons that do not apply to ordinary failures.

It is total. Nothing loads. Not a cached page, not a static asset, not the error page you carefully designed. The failure happens before any HTTP is exchanged, so every mechanism you have for degrading gracefully is downstream of the point where it stopped.

It looks like an attack. The browser does not say the site has a maintenance problem. It says the connection is not private and implies someone may be intercepting it. A visitor who has never thought about certificates concludes the site has been hacked, and some of them will say so publicly.

It takes everything that is not a browser with it. Mobile applications talking to the API, the payment provider's webhook, the client's own integrations, the mail client fetching from the same hostname. None of those has a human to click through, and several will retry, fail, and eventually give up in ways that need manual repair afterwards.

The visitor may have no way past it. Which brings us to the setting that turns an inconvenience into a wall.

HSTS removes the escape hatch

Certificate warnings normally offer a way through, buried under an "advanced" toggle. It is a bad idea to use it and it exists.

If the site has previously sent a Strict-Transport-Security header, and the browser has remembered it, that option is gone. The specification requires browsers to refuse the bypass for hosts under HSTS, and they do. A visitor who has been to the site before, which is to say your client's regular customers, cannot reach it at all until the certificate is fixed. Someone who has never visited may still get the click-through, which produces the confusing report that the site works for the client's new intern and not for anyone in the office.

This is not an argument against HSTS. It is an argument for knowing that enabling it converts certificate expiry from a degraded state into a hard outage, and for setting the alerting accordingly on any host that sends the header.

The first ten minutes, when it has already happened

In order, because the second step resolves this more often than the rest combined.

One. Read what the server is serving, from outside. Not the file on disk, not the panel. The command above, from a machine that is not the server.

Two. Check whether a valid certificate already exists on the box. This is the most common shape of the incident by a wide margin: the renewal ran, the new certificate is sitting in the filesystem, and nothing reloaded the service that reads it. The server is happily serving a certificate it loaded into memory weeks ago.

openssl x509 -noout -enddate -in /etc/letsencrypt/live/example.com/fullchain.pem

If that date is in the future and the served date is not, you do not have a certificate problem. You have a reload problem, and it is one command away from over. This is also why a renewal hook that reloads the service is not optional, and why renewal success is a weaker signal than most people treat it as: renewal is three operations and any of them can fail alone.

Three. Tell the client, in one sentence, before you fix it. They are about to receive messages from customers saying the site has been hacked. Forty seconds of pre-emption is worth an hour of reassurance afterwards.

Four. Issue a new one. With an automated authority this is minutes, assuming the validation path still works. With a commercial authority it depends on the account, the payment method, and whether anyone at the client can approve it, which is precisely why this step should never be the first time you find out who that person is.

Five. Verify from outside again, and check the chain while you are there. A hurried reissue is a common origin for a missing intermediate, which then works in browsers and fails for the payment webhook a fortnight later.

The hostnames this happens to

Not the main site. The main site is in the automation, it renews, and somebody would notice.

It happens to the hostname that fell outside the automation. The domain retired in a rebrand that still redirects. The mail hostname. The staging copy. A load balancer terminating TLS with a certificate managed separately from the origin's. An internal service with a certificate somebody generated by hand two years ago. In each case the name is real, the traffic is small, nobody looks at it, and the certificate lapses without a single complaint until something that depended on it breaks in a way nobody connects to TLS.

The remedy is boring and it is the only one that works: the list of hostnames you check is the list of hostnames that exist, not the list of sites you think about. Building that list from DNS and from the servers, rather than from memory, is the difference between coverage and the feeling of coverage.

What it costs, and what prevention costs

Prevention is a date in a file and an alert with enough margin to act on. Not an alert on the expiry date, which fires when the window has already closed, and not one so early it becomes background noise. Far enough out that a person can find the right account and get a decision from the client.

Against that: a total outage of unpredictable length, during which the site tells every visitor it might be compromised, and every non-browser integration fails silently. There is no other failure in this business with such a wide gap between the cost of prevention and the cost of the event, and none where the event is so precisely predictable.

If you want to see what a hostname is currently serving, dates and chain included, without setting anything up, run it through the checker.