SSL/TLS Certificate Renewal Checklist
An SSL certificate renewal checklist: find every copy, renew with the right SANs, deploy the full chain, verify from outside and set expiry alerts in time.
- Typical schedule per certificate renewal
- The checklist 5 sections, 19 items
- Variables
{{domain}}
An expired certificate is one of the most avoidable outages there is, and it still happens to experienced teams. Use this checklist when a certificate is renewed manually or semi-manually: a purchased OV or EV certificate, a wildcard certificate copied to several systems, or anything not covered by fully automated ACME renewal (e.g. Let's Encrypt with certbot or Caddy). Certificate lifetimes are getting shorter across the industry, so renewal will happen more often, not less.
Who owns it
Each certificate needs a named owner, not just "IT". The owner starts the run well before expiry, renews the certificate, deploys it everywhere it is used and confirms the new expiry date from the outside.
Common pitfalls
- The forgotten copy. A wildcard certificate often lives on the load balancer, the CDN, a mail server, a VPN appliance and a developer's laptop. Renew one and the others still expire.
- Missing intermediate certificate. Browsers may cope, but API clients, mobile apps and older systems fail. Always deploy the full chain.
- Renewal reminders to a former employee. Expiry notices from the CA go to whoever bought the certificate. Use a shared mailbox.
- Automation that silently stopped. ACME renewal can break after a DNS or firewall change. Monitor the expiry date itself, not just the renewal job.
Create a Runbook run when the expiry alert fires, so the renewal has an owner and a record of where the new certificate was deployed.
The checklist: Renew TLS certificate for {{domain}}
Prepare
-
Current certificate for
{{domain}}inspected: expiry date, SANs, key type and issuing CAe.g. openssl s_client -connect
{{domain}}:443 -servername{{domain}}</dev/null | openssl x509 -noout -dates -ext subjectAltName -
Every system using this certificate listed: load balancers, CDN, web and mail servers, VPN, appliances
-
Renewal started early enough to allow for validation delays
-
Domain validation method confirmed: DNS record, HTTP file or email
-
Organisation validation details current, for OV or EV certificates optional
Renew
-
New private key and CSR generated with the same or stronger key settings
Generate a new key rather than reusing the old one. Store it only where it is needed.
-
All required hostnames included as SANs in the CSR
-
Certificate issued and the full chain (leaf plus intermediates) downloaded
-
Private key stored securely, e.g. in a secret manager, with restricted file permissions on servers
Deploy
-
New certificate and chain installed on every system on the list
-
Services reloaded or restarted so they serve the new certificate
-
Certificate pinning or trust stores in clients and partner systems updated optional
Verify
-
Each endpoint checked from outside: new expiry date and correct hostname
-
Full chain served with no missing intermediate, checked with an SSL test tool
-
Non-browser clients tested: API consumers, mobile app, mail delivery optional
Close out
-
Expiry monitoring updated or confirmed for the new date
-
Old private key and certificate files removed from servers
-
Certificate inventory updated with expiry, locations and owner
-
Automatic renewal evaluated for next time, e.g. via ACME optional
Checklist as Markdown
Frequently asked questions
How far in advance should I renew an SSL certificate?
Start well ahead of expiry, typically a few weeks for purchased certificates, to allow for validation and deploying to every system. Check your CA's rules on whether remaining validity carries over, since maximum lifetimes are shrinking. ACME clients such as certbot renew automatically well before expiry.
What happens when a TLS certificate expires?
Browsers show a security warning and most users will not continue. API clients, mobile apps and integrations usually refuse to connect at all. To users, an expired certificate looks like a full outage, even though your servers are running.
How do I monitor certificate expiry?
Use an external uptime or certificate monitor (e.g. Gatus, Uptime Kuma or your monitoring platform) that checks each public endpoint and alerts well before expiry. Also keep a simple inventory of certificates, where they are deployed and who owns them. Certificate Transparency logs can help you find certificates you did not know about.
Updated