The SSL Certificate Renewal Checklist for Agencies

Why renewals still break in 2026

Most certificates are now free and short-lived — Let's Encrypt issues for 90 days, and the industry is moving toward even shorter maximum lifetimes. That is good for security and bad for anyone relying on human memory. A cert that renewed itself for two years can silently stop renewing after a server rebuild, a changed DNS provider, or a firewall rule that blocks the ACME challenge.

The failure is rarely the certificate authority. It is a broken automation nobody noticed, an intermediate that stopped being served, or a second load balancer that never got the new cert. An agency managing dozens of domains needs a checklist precisely because the failure modes are boring and easy to skip.

The SSL certificate renewal checklist

Run this per domain, ideally 30 days before expiry so you have room to fix problems before they become incidents:

• Confirm the real expiry date from the live endpoint, not from a spreadsheet — check with `openssl s_client -connect host:443 -servername host` or a quick lookup in the SSL checker.
• Verify every hostname the cert must cover, including www, apex, and any regional or app subdomains. A renewed cert that dropped a SAN entry breaks silently for one audience.
• Check that automated renewal actually ran and reloaded the service — a renewed file on disk that the web server never picked up is still serving the old cert.
• Confirm the ACME challenge path (HTTP-01 or DNS-01) is still reachable after any infrastructure change.
• Validate the full chain is served, not just the leaf (see below).
• Reload or restart every node that terminates TLS — load balancers, CDNs, reverse proxies, and origin servers can each hold a stale copy.
• Re-test from an external vantage point once the new cert is live.

Validate the chain, not just the leaf

A certificate almost never validates on its own. The browser needs an unbroken path from your leaf certificate, through one or more intermediates, up to a root already trusted by the client. The single most common post-renewal failure is a server that serves the leaf but forgets the intermediate — it works in your desktop browser (which caches intermediates) and fails on a fresh mobile device or an API client.

After every renewal, confirm the server sends the leaf plus all intermediates in the correct order. Test from a clean client or a tool that does not cache, and treat 'works on my machine' as unproven until an external check agrees.

Automate with ACME where you can

Manual renewal does not scale past a handful of domains, and it will eventually be forgotten. Use an ACME client — certbot, acme.sh, Caddy's built-in automation, or your platform's managed certificates — and prefer DNS-01 challenges when a domain sits behind a CDN or has multiple origins, since it validates once regardless of how many servers answer.

Automation is necessary but not sufficient. An ACME cron job that fails quietly is worse than a manual process, because everyone assumes it is handled. The job needs to fail loudly, and something outside the server has to confirm the public endpoint actually updated.

Monitor so nothing slips through

The checklist above catches the renewal you remembered to do. Monitoring catches the one you forgot and the automation that broke. Watch the live endpoint from the outside, alert at 30, 14, and 3 days before expiry, and flag chain or hostname mismatches as their own signal rather than waiting for a hard failure.

If a cert has already lapsed, work through our SSL certificate expired fix first, then set up monitoring so it cannot recur. Agencies especially should read SSL monitoring vs uptime monitoring — a green uptime check tells you the site loads, not that the certificate is healthy.