Ask an infrastructure team about their availability risks and you will hear about power, disks, network paths and dependencies. You will rarely hear about certificates, which is odd, because an expired certificate is a scheduled outage that arrives on a date known years in advance.
Why it keeps happening
The certificate was installed by someone who has left. It is on a system nobody owns. The expiry date is in a spreadsheet that is not maintained, or in an email calendar reminder belonging to a person who changed teams.
The renewal requires a process — a request, an approval, a private key, an installation, a restart — that somebody has to remember how to do, and that somebody last did it two years ago.
None of these are technical problems. All of them are reliably fatal.
Where they hide
The obvious ones are on public websites and are usually monitored. The ones that cause incidents are elsewhere:
Internal service-to-service certificates. Load balancer certificates for internal applications. Database connection certificates. Kubernetes cluster certificates, which are rotated automatically until the day the automation fails. Directory service certificates, which break authentication broadly when they go. Management interfaces. VPN gateways. Code signing certificates. Client certificates on devices.
The pattern: anything not visible from the internet is not being checked by anything external, and internal monitoring rarely checks certificate expiry unless somebody deliberately added it.
The three things that fix it
Inventory by scanning, not by asking. Scan your own address ranges and record every certificate found: subject, issuer, expiry, and which host. Run it weekly. A spreadsheet maintained by hand is out of date the day it is written; a scan is current by construction.
This catches the certificates nobody remembers, which are exactly the ones that cause incidents.
Alert well ahead, to a team. Not thirty days, which is too short for anything requiring procurement or a change window. Sixty and thirty and seven, escalating, going to a team address rather than an individual. An alert to a person who has left is not an alert.
Automate renewal wherever the protocol allows. ACME-based automated issuance is available for public certificates and, with an internal CA, for internal ones too. A certificate that renews itself every sixty days cannot expire through forgetfulness, and the short lifetime forces the automation to be correct because it is exercised constantly.
Short-lived automated certificates are safer than long-lived manual ones, which is counterintuitive to anyone whose instinct is to buy the longest validity available. The long validity is precisely what lets the renewal knowledge decay.
The organisational fix
Give certificates an owner in the same way disks and networks have owners, and put expiry on the availability dashboard rather than in a security report.
The filing matters. Under security, it is somebody’s compliance item reviewed quarterly. Under availability, it is an operational metric that gets watched, and a pending expiry looks like what it actually is: a countdown to an outage.
The test
Ask how many certificates are in your environment and when the next one expires. If the answer requires research, you have the problem, and the research is worth doing this week rather than at 3am on the day it matters.