TLS certificate deployment checklist
Use this checklist after issuing or replacing a certificate. It is designed for services where traffic may pass through more than one layer before reaching the application.
Before the change
- Record the exact hostnames and wildcard names the certificate should cover.
- Identify every public listener: CDN, WAF, reverse proxy, ingress, load balancer, and origin.
- Confirm the key and certificate files are handled through the approved secrets process.
- Confirm the intermediate chain required by the serving software.
- Define the rollback certificate and the owner for the change.
During deployment
- Install the certificate on every intended serving node or managed endpoint.
- Reload the service using its documented configuration validation step.
- Check that the reload succeeded and that no node was skipped.
- Keep the private key out of logs, tickets, chat, and browser uploads.
After deployment
- Connect using the real hostname and SNI.
- Confirm the new expiration date, SAN coverage, issuer, and signature/public-key details.
- Check the chain from a representative public client.
- Test the CDN/proxy path separately from the origin path when both matter.
- Record the fingerprint, verification time, and next renewal owner.
Do not rely on the origin alone: a healthy origin can coexist with a stale certificate at the CDN, load balancer, or alternate hostname.
Run a public endpoint check or read the certificate chain guide when the post-deployment result is unexpected.
Last reviewed: October 2026. Adapt the checklist to your provider’s current deployment and rollback procedures.