The SSL Certificate Nobody Renewed

Take a small online store. The certificate on its domain expires at three in the morning. Nothing crashes. The server answers every request the way it always has. No error shows up in the logs, because from the server's side nothing has gone wrong.

From the visitor's side, everything has. Each new browser that arrives gets a full-page warning saying the connection is not private. Most people read that as "this shop has been hacked", and they leave. The ones who came from a paid ad leave too, and the ad still gets charged.

The owner checks the site the next morning and it looks fine. Their browser still has a warm connection, or they open it on a laptop that never closed the tab. Two days later a customer emails to ask if the store is safe. That is two days of revenue and ad spend gone, lost to a renewal that could have been done at any point in the previous month.

None of this is unusual. It is the most predictable outage there is. The date is printed in the certificate.

Why expiry hides so well

Most failures leave a trail. Response times creep up, error rates climb, and something in your monitoring starts to look wrong before anything actually breaks. An expiring certificate leaves no trail at all. It works perfectly at 02:59 and fails completely at 03:00.

The usual safety nets miss it for good reasons:

• The owner's browser lies. Browsers reuse open connections and cache sessions. The person most likely to check the site is the one least likely to see the warning.
• The server is healthy. CPU, memory, disk and the application are all fine. Anything that watches the server from the inside sees nothing to report.
• A plain HTTP check can pass. A probe that skips certificate validation, or only checks the http:// address, gets a perfectly good response.
• Nobody is assigned to look. Few people check the live site on purpose, and the ones who do assume someone else has already noticed.

"But it renews automatically"

Most certificates today are issued by an automated authority and renewed by a script. That is a big improvement, and it also means a renewal now fails quietly instead of being forgotten by a person. The common ways it breaks:

• The renewal job stopped running. A server was rebuilt, a cron entry was lost, or a container image no longer includes the renewal timer.
• The challenge fails. A DNS change, a new CDN or a redirect rule stops the authority from validating the domain. The client logs an error that nobody reads.
• The new certificate never loads. The renewal succeeds and writes a new file to disk, but the web server keeps serving the old one from memory until it is reloaded. The new file sits there unused while the old one expires.
• The certificate lives somewhere else. A load balancer, a CDN or a hosting panel holds its own copy, and the automation renews a different one.
• The card on file expired. For paid certificates, the renewal goes through the same billing account as everything else, and the warning about the failed payment goes to the same inbox as everything else.

Automation moves the risk around without removing it. You still need something that checks the certificate visitors are actually being served, from outside, on a schedule.

Layer one: warnings with enough time to act

The first layer reads the expiry date before anything breaks. Barkme checks the certificate on every verified domain once a day and warns at 30, 14, 7 and 1 days before it expires. Each threshold fires once, so the warnings stay rare enough that people still read them.

Thirty days is long enough to fix the slow problems: an account nobody can log into, a renewal that needs someone else's approval, a CDN setting that has to change. Seven days says it has to happen this week. The one-day warning is the last chance before visitors start seeing the warning page.

Send these warnings to someone who can actually renew. For a small store, that usually means a phone, not a shared inbox. Telegram or Slack work well, and email is fine if it goes to a person rather than a role address.

Layer two: count a TLS failure as down

The second layer catches the expiry that slips through anyway. Barkme counts a failed TLS handshake the same as a 500. If the certificate expires, the monitors on that domain start failing, an incident opens within minutes, and you hear about it the same morning instead of from a customer days later.

That is also why a monitor should point at the https:// address of a page that matters, like the cart or the checkout, and not only at the homepage over plain HTTP.

A short checklist

1. Verify the domain so its certificate is checked daily.
2. Send expiry warnings to a channel a person reads, not a shared inbox.
3. Monitor at least one https:// page that makes money.
4. After every renewal, check that the served certificate actually changed.
5. Write down where each certificate lives: the server, the load balancer or the CDN.

None of this takes long. The certificate tells you exactly when it will fail, so the only real mistake is not reading the date.

Domain monitoring and SSL alerts covers what Barkme checks and where the warnings go. For a one-off look at any domain, the free domain health check shows the certificate expiry date in a few seconds. The background is in how SSL and TLS work, and the slower cousin of this story is the domain that lapsed.