Three client sites, three expired certificates, one Monday morning

Fictional composite again, same disclaimer: the pattern is real, the studio is not.

A two-person agency maintains twenty-six sites for small businesses. Certificates are issued by three different providers depending on which host each site ended up on — a managed host with auto-renew, a VPS with certbot, and a couple of sites still on a shared plan where renewal is manual and the login belongs to a client who has changed accountants twice.

Auto-renew is not the same as renewed

The managed host renews automatically and is fine. Certbot is fine as long as the renewal timer was never disabled during a migration — and on one box it was, in March, by a technician who then left. The shared-plan site is manual, and the reminder went to the client.

On Monday morning three sites serve an expired certificate. Browsers show the interstitial. Two of them are for businesses that get most of their customers through that page. None of this is a security incident; all of it is a revenue incident.

The check that would have caught it

Perimeter connects on a schedule and reads the certificate the way a browser would: subject, issuer, validity window, chain, negotiated TLS version and cipher. Expiry is stored as days remaining, so 76 days out is a number you can sort by, and 7 days out is an alert.

• Expiry — warned at 30 and 7 days, plus the chain-validity flag.
• TLS — a handshake that only offers obsolete protocol versions is a finding, not a detail.
• DNS — A, MX, TXT, NS and CAA presence, so a missing mail route is visible before a customer reports it.

The part that actually saves the afternoon

Knowing that a certificate expires in four days is half the job. The other half is the ten minutes of remembering which provider issued it, where the renewal runs and which account owns the DNS. That context is what disappears when the person who set it up leaves.

So each finding now carries the fix rather than only the symptom: what the receiver or browser does with the broken configuration, the ordered steps to repair it, the record to publish, and the RFC that backs the claim. It does not run the fix — it removes the part where you have to go and re-derive it at 9am on a Monday.

An honest note about certificates you do not control

If the certificate is issued by a provider that renews on its own, monitoring it is still worth it — you are monitoring the renewal, not the certificate. The one thing monitoring cannot do is fix a CAA record that forbids your CA from issuing. That still needs a human, and the finding will at least say so.