What breaks when a cert expires
An expired SSL certificate does not wait for a convenient Tuesday. Browsers show a scary interstitial, API clients refuse the connection, and mail clients may stop trusting your server—often while your homepage still “looks fine” to anyone who never hits HTTPS warnings. For small businesses, the fix is not more jargon. It is an inventory, a named owner, and calendar reminders at 30, 14, and 7 days.
This is an operator checklist TwoQM recommends—not a PKI deep dive.
When a certificate passes its Not After date, trust fails in different places at once:
Browsers — Chrome, Safari, Edge, and Firefox show interstitial warnings (“Your connection is not private”). Many visitors leave.
API and mobile clients — Apps and integrations that validate TLS often fail hard with no friendly UI.
Mail — IMAP/SMTP/webmail over TLS can break or warn when the mail hostname’s cert expires.
Webhooks and monitoring — Partner HTTPS calls stop; uptime tools flip red.
One missed renewal on one hostname is enough.
Inventory every certificate—not just the homepage
Start with a shared spreadsheet. List every place a cert is presented:
Apex — example.com
www — www.example.com (often a separate cert or SAN entry)
Mail — mail., webmail., or the hostname your IMAP/SMTP actually uses
Staging / preview — staging., dev., host preview URLs
CDN / edge — Cloudflare or other edge certs in front of origin
Load balancer / reverse proxy — cloud LB, nginx, cPanel AutoSSL, host-panel SSL tabs
Wildcards — *.example.com (renewal still has a date)
Forgotten subdomains — booking, shop, portal, VPN, helpdesk
For each row: hostname(s), issuer, Not After, storage (panel, Cloudflare, LB, ACM), auto-renew on/off, and who owns renewal. Reassign if the owner already left.
Auto-renew vs manual CA
Most small-business stacks fall into one of these buckets:
Let’s Encrypt via host panel / AutoSSL / Certbot — Usually auto-renews if the challenge still works (HTTP-01 or DNS-01). Breaks when DNS moves, a WAF blocks /.well-known/acme-challenge/, or the panel job is disabled.
Cloudflare (or similar) edge SSL — Edge certs renew in-product; origin certs are a separate problem. Do not assume “CDN is on” means origin TLS is healthy.
Host panel one-click SSL — Fine until the renew job fails silently after a domain or nameserver change.
Load balancer / cloud certificate manager — Automatic only if DNS validation records still exist and listeners still point at the right cert.
Manual CA purchase — Email reminders help only if the contact mailbox still exists. Put the dates on your calendar anyway.
Auto-renew is a feature, not a guarantee. Treat it as “usually works” and still calendar the expiry.
Calendar reminders: 30 / 14 / 7 days
For every cert on the inventory, create three events on a shared team calendar:
30 days — Confirm auto-renew is enabled and the challenge path still works. Dry-run renew if your tooling supports it.
14 days — Verify the next renew window; fix DNS/WAF/panel blockers now, not on expiry day.
7 days — Escalate: named owner confirms renew succeeded or schedules a manual reissue. Do not wait for customer screenshots.
Include hostname, issuer, and owner initials in the event title. A vague “SSL check” event gets skipped.
Pitfalls that kill “set and forget”
Split brain — Apex on host AutoSSL, www on Cloudflare, mail on a third panel. Three expiry clocks.
Staging left on a short-lived cert — Demo links die mid-sales cycle.
DNS change without renewing ACME — Let’s Encrypt renew fails after nameserver moves or port 80 blocks.
CDN hiding origin expiry — Visitors see the edge cert while origin or direct checks fail.
HSTS already enabled — After expiry, remembered HSTS makes “just use HTTP for a minute” impossible. Renew before you lean on HSTS.
Wrong CA contact email — Renewal mail goes to a defunct inbox.
Document each renew path like you document who owns production deploys.
Post-renew smoke checks
After every renew (auto or manual), do not close the ticket until:
Padlock / HTTPS — Incognito load of apex and www over https://; no interstitial, no name mismatch.
Hostname match — Cert SANs cover the names you actually type (including redirects).
Mixed content — DevTools console clean of blocked http:// assets on key pages.
HSTS — If you serve Strict-Transport-Security, confirm HTTPS still works end-to-end.
Mail hostname — If mail uses TLS on a named host, check that cert too—not only the website.
API / webhook — Hit one HTTPS integration path if partners call you.
Monitoring — Confirm SSL monitors show the new Not After date.
Log date, hostname, issuer, new expiry, and owner initials.
Same-week checklist
Spreadsheet of every hostname that presents TLS
Issuer, Not After, storage location, auto-renew yes/no
Named owner for each renew path
Calendar events at 30 / 14 / 7 days (shared calendar)
ACME / panel / Cloudflare / LB renew path documented
WAF and DNS challenges verified for Let’s Encrypt hosts
Post-renew smoke: padlock, SAN match, mixed content, HSTS, mail host
Monitoring alerts updated to the new expiry
Owner initials and timestamp in the change log
Make expiry boring
SSL expiry incidents feel dramatic because customers see them first—almost always calendar failures, not cryptography failures.
TwoQM’s bias is simple: inventory every cert, name an owner, put 30/14/7 on a shared calendar, and smoke-test after renew. Browsers should never be the first system that tells you a certificate died.