Guides

The certificate expires on Saturday: who tells you in time?

In short

A certificate has an expiry date printed on it, which makes it the most preventable outage there is and the most embarrassing to have. Automatic renewal covers the public website and almost nothing else: the terminal, the recorder's interface, the mail server and the appliance in the rack each have their own, and nobody is counting their days.

Almost every outage arrives without warning. This one arrives with a date printed on it, visible to anybody who looks, sixty days in advance. And it still happens, every year, to organisations that are otherwise well run.

Why do certificates still expire without anyone noticing?

Because the thing that is automated is not the thing that expires.

Automatic renewal took care of the public website years ago, and with it the sense that the problem was solved. Meanwhile certificates multiplied into places no automation reaches: the payment terminal in the shop, the web interface of the video recorder, the mail server, the VPN appliance, the internal dashboard, the machine that talks to a supplier’s API. Each of them presents a certificate. None of them is in the renewal script.

The second reason is more annoying: renewal that works and changes nothing. The new certificate is written to disk, the job reports success, and the service keeps serving the old one because nothing told it to reload. From the outside — which is the only side your customers are on — that is indistinguishable from never having renewed at all.

The third is the quiet one: a device that only reveals its expired certificate when it restarts. It ran for eleven months without a reboot. Then there is a power cut on a Friday night, and on Saturday morning it refuses to come up.

How many days of warning do you actually need?

Start counting sixty days out, and count on the certificate as it is actually served, not as it exists in a file. That single distinction catches the renewed-but-not-reloaded case, which is the most common one in practice.

Then escalate deliberately. Two months out, a note is enough. At two weeks, it should reach a channel people actually read during the day. In the last few days, it should interrupt someone — a certificate that expires on a Saturday morning was already visible on Wednesday. And once the date has passed, it should come back every day, without mercy, because it is no longer a warning: it is an outage that is still happening.

Alongside it, watch the domain. Its expiry, its registrar, its nameservers. That information is published by the registry itself, so there is no excuse for not knowing — and an unexpected change in it is either a mistake or somebody else’s doing, and both are worth a phone call.

Do you know how many certificates you have?

Probably not, and that is the real difficulty: not the counting, but knowing what exists.

Most organisations cannot list their own certificates. The site, yes. The shop’s terminal, probably not. The recorder’s interface, almost certainly not. The subdomain someone published for a campaign in 2023, no. You cannot count down the days on something you have forgotten you have, and this is where the expensive Saturdays come from — never from the certificate everybody remembers.

So start with the list. Take the domains you control and find what is published under them, add the devices that present a web interface even if only you use it, and then count. The list itself is usually the finding.

What to do this week

  1. Write down every address that presents a certificate, including the ones only staff use. Expect the list to be longer than you thought.
  2. Put every one of them on a countdown, measured against what is served, not against a file.
  3. Set the escalation now: a message weeks out, a louder one at two weeks, a real interruption in the last days, and a daily reminder once expired.
  4. Add the domain’s own expiry date, and check who the registrar and the nameservers are while you are there.
  5. For each certificate that renews automatically, verify once that the service actually reloads. That five-minute test is the whole difference.

There is no such thing as being surprised by a certificate. There is only not having counted.

What we cannot tell you

  • We cannot see a certificate on something we are not watching: we read what a service presents on its port, so a device you have not told us about stays invisible, whatever is about to expire inside it.
  • We cannot renew a certificate for you, and we cannot restart the service that is still serving the old one after a successful renewal.
  • We cannot see a certificate that is never presented over the network — one sitting in a configuration file, a keystore or a signing chain that nothing serves.

Questions people actually ask

We have automatic renewal. Is that not solved?

It is solved for whatever is inside the automation, which is usually the public website and nothing else. The payment terminal, the recorder's web interface, the mail server, the appliance in the rack and the internal tool someone set up in 2021 each have a certificate of their own, renewed by hand or not at all. Those are the ones that expire on a Saturday.

Renewal ran successfully and the site still shows an expired certificate. How?

Because renewing and serving are two steps. The new certificate is on disk and the service is still holding the old one in memory, because nothing reloaded it. It is one of the most common versions of this failure, and from outside it looks identical to no renewal at all — which is exactly why the check has to be made from outside, against what is actually served.

How much warning is useful?

Enough to act, then increasing pressure. Counting down from sixty days gives you time to plan; a reminder at two weeks reaches a different channel; inside the last few days it deserves to interrupt someone. And once the date has passed, the warning should come back every single day, because an expired certificate is not a notification, it is an ongoing outage.

What about the domain itself?

The same shape of failure with a bigger blast radius: an expired domain takes down the site, the mail and anything depending on it, and recovering it is not always quick or cheap. Watch the registry's own record for the expiry date, the registrar and the nameservers — and treat any unexpected change there as a serious event, because it is either an error or someone else's work.

Is an expired certificate an outage or a warning?

For your visitors it is a full outage: browsers refuse, terminals refuse, integrations refuse. Internally it deserves its own colour — the service is answering, but nobody can use it. Treating it as merely degraded is how it survives a weekend.

Updated September 18, 2026 · Angelo Barbosa