Home / Blog / SSL Certificate Renewal Checklist

SSL Certificate Renewal Checklist

Certificate Monitoring By Alex Chen 6 min read

Certificate renewal should be a non-event. In most organizations, it isn't. The renewal itself is usually straightforward, but the steps around it (verifying the new cert before deployment, deploying to every backend, confirming the chain serves correctly) are where things go wrong.

This is a working checklist for renewing a TLS certificate without causing an outage. It's organized by phase: before renewal, during, and after. Use it as a reference, not a script.

Before Renewal

Most renewal failures are diagnosed during this phase. Running through the list here prevents problems from showing up under time pressure.

Confirm the certificate's current state.

  • Check the current notAfter date and confirm you're renewing with enough buffer (at least 2 weeks before expiry for most cases).
  • Verify all SANs on the current certificate. The renewal should cover the same set unless you've explicitly decided to change coverage.
  • Note the current fingerprint. You'll want this for comparison after deployment.

The SSL Certificate Check on Mr. DNS gives you all of this in one query.

Verify DNS configuration.

  • Confirm DNS resolves to every expected backend. A DNS change during renewal is the easiest way to cause a mismatch.
  • Check CAA records allow the issuing CA. A restrictive CAA record that was fine last renewal may have been updated since. Verify with the DNS Lookup on Mr. DNS.
  • If using DNS-01 validation, confirm the DNS provider's API access is still working and TTLs are low enough for fast propagation.

Check automation state.

  • If using an ACME client, verify the client is installed and the renewal timer is enabled. For certbot: systemctl status certbot.timer.
  • Review recent renewal logs. A renewal client that "successfully" ran yesterday may have been failing silently for weeks.
  • Confirm the account credentials are current. Expired API keys or account deactivation are silent automation killers.

Identify every deployment target.

A certificate rarely lives on one server. For each renewal, enumerate:

  • Every web server behind the load balancer
  • STARTTLS services (SMTP, IMAP, LDAP, FTP) that need the same certificate
  • CDN origins that need the new certificate
  • Any backup or standby systems that maintain their own certificate copy

Missing a deployment target is the most common cause of post-renewal mismatches.

During Renewal

Issue and validate before deploying.

Never deploy a certificate that you haven't verified off-production. Issue the certificate to a staging location first and confirm:

  • The leaf certificate is valid and has the expected SANs
  • The full chain is present (leaf + intermediates; the root is typically in the client's trust store)
  • The private key matches the certificate (openssl rsa -in key.pem -modulus -noout vs openssl x509 -in cert.pem -modulus -noout)
  • The certificate's notAfter is as expected (issuance mistakes happen)

For commercial CAs, the delivered bundle sometimes ships with an incomplete chain. Confirm the intermediate certificates are included, or you'll serve a valid leaf with a broken chain and see browser errors despite having "renewed."

Deploy atomically where possible.

For systems with many deployment targets, stagger the deployment to limit blast radius:

  1. Deploy to one backend first
  2. Verify that backend serves the new certificate correctly
  3. Deploy to remaining backends in batches
  4. Monitor error rates between batches

For load-balanced pools, a pool-level deployment tool (Ansible, Puppet, or equivalent) is faster and less error-prone than manual deployment. Either way, make sure you can quickly roll back if the new certificate has an unexpected problem.

Reload services, don't just copy files.

Copying a certificate file doesn't activate it. Each service has its own reload mechanism:

  • Nginx: nginx -t && systemctl reload nginx
  • Apache: apachectl configtest && systemctl reload apache2
  • Postfix: postfix reload
  • HAProxy: systemctl reload haproxy or dynamic reload via runtime API

Test the configuration first, reload second. A syntax error means the service stays on the old (still valid) configuration instead of crashing, but only if you test.

After Renewal

Verify from outside your network.

Internal verification doesn't prove anything. The certificate needs to serve correctly from clients, not from the deployment server.

  • Check the hostname from multiple locations. A certificate that only serves correctly from the deployment server isn't deployed correctly.
  • Use the DNS Propagation Checker to confirm DNS is consistent globally.
  • For each backend IP behind the DNS hostname, verify independently. Many certificate issues only appear when you query the IPs directly, bypassing DNS.

Confirm the chain serves correctly.

The fastest way to verify: open the site in an incognito browser window. Modern browsers will flag chain problems immediately. For automated verification, openssl s_client -connect host:443 -servername host -showcerts displays the full chain as served.

Update the inventory.

Record the renewal:

  • New fingerprint
  • New expiry date
  • Any SAN changes
  • Deployment targets updated (and any that were skipped or failed)

An accurate inventory is what makes the next renewal simpler and what supports automation going forward.

Confirm monitoring caught the change.

If your monitoring system didn't detect the new certificate's deployment, it won't detect a bad one either. Confirm the new fingerprint shows up in monitoring. If the monitoring system alerted on the fingerprint change, that's working as intended. If it didn't, check why.

Review rollback readiness.

Keep the previous certificate in an accessible location for at least 24 hours after renewal. The odds you'll need it are low, but the cost of needing it and not having it is high.

When Things Go Wrong

If a renewal causes an outage, the SSL Certificate Expiry Response Playbook covers the triage order and recovery paths. Most post-renewal incidents resolve in under 15 minutes if the team knows where to look.

Automating the Checklist

Everything on this list can be automated, and for any organization managing more than a handful of certificates, it should be. The checklist is what you run through manually the first few times; the monitoring and renewal tooling are what runs it every time after.

Generator Labs certificate monitoring handles the verification phase automatically: detecting the renewal, confirming the new chain is valid, verifying every backend IP, and alerting if anything is inconsistent. The operational goal is simple: renewals become maintenance events that run in the background, not coordinated deployments that need oversight.

Back to Blog