SSL Certificate Expiry Checklist for Small Teams

The certificate expiry outage is the most predictable incident in small-team ops: the tooling existed to prevent it, the renewal "was automatic," and at 11pm on a Friday the browser warning page is standing between your customers and the checkout. The honest fix has four parts: inventory every cert, alert on what is actually served, rehearse the renewal, and write the runbook for when it's already too late.

1. Inventory first (the website is not the only cert you own)

Most teams monitor one certificate — the public site — and get surprised by the other four. Your inventory is a single table with one row per hostname that terminates TLS:

Include the unglamorous endpoints: the load balancer's own cert, SMTP/IMAP on the mail host, the VPN gateway, the billing portal someone bought separately in 2023. Internal certs nobody watches are the ones that take down the admin panel at the worst time.

2. Alert on what is served, not what is configured

• Turn on the expiry check for every hostname — nearly every monitoring product (including the one you already pay for) has a certificate-expiry toggle. It probes the live endpoint, so it catches the cert that renewal deployed-but-didn't-reload.
• Alert at 30 / 14 / 7 / 3 / 1 days into the channel people actually read. A 30-day warning in an abandoned channel is the same as no warning.
• Alert the "renewal failed" signal separately. ACME bots log failures before expiry; a renewal that failed twice deserves a louder ping than the expiry countdown itself.

3. Automate renewal, then distrust it

Automation is the right default: ACME/Let's Encrypt for public hosts, cert-manager on Kubernetes, managed certs at the CDN. But automated renewals fail in three silent ways, and all three look like "it's fine, it renews automatically":

4. The quarterly dry-run (15 minutes that buy the year)

1. Force a renewal in staging — certbot renew --dry-run, or cert-manager's self-check, or the CDN's "renew now".
2. Verify the full chain is served: a missing intermediate passes in the bot's logs and fails for a chunk of real browsers. openssl s_client -connect host:443 -servername host and read the chain, not just the leaf.
3. Confirm the service actually reloaded — the served notBefore moved, not just the file on disk.
4. Write down what broke. That note is next quarter's checklist.

5. The already-expired runbook

When the warning page is live, sequence matters less than speed, but do it in this order:

1. Renew and deploy now — the emergency path, not the elegant one. Manual renewal on the edge is fine at 11pm.
2. Verify from outside — phone hotspot, not office wifi: chain complete, hostname matches, stapling intact if you use it.
3. Assume hours, not seconds, of residual breakage — mobile carriers, DNS resolvers and browser caches hold the old cert; some clients keep failing after your check says green.
4. Tell customers before they tell you — a status note beats a support queue full of screenshots. The words you need are already in the incident communication templates.
5. Postmortem the silence — the cert expired, but the incident is that nobody knew for hours. Fix the monitoring, not just the cert.

6. The checklist

The three rules that make the checklist work

• Monitor what's served, not what's configured. A renewed file behind an unreloaded server is an outage wearing a green dashboard. Probe the endpoint.
• A renewal you haven't rehearsed hasn't happened. "It's automated" is a hypothesis; the quarterly dry-run is the experiment.
• The dangerous cert is the one nobody watches. The public site has an expiry banner; the VPN gateway has nothing. Inventory is the whole point.

---

The Ops Starter Kit ($14) turns the first-hour chaos of any outage — expired cert included — into a fillable plan, and Vol. 2 ($27) adds the DR plan and evidence log for the review after. Launch week: 30% off any paid kit with code HIVE-LAUNCH30 at checkout (ends Sep 11, 23:30 ACST).