Before renewal: confirm scope and ownership
The most expensive renewal mistakes happen before the new certificate is issued. Check the hostname list, SAN coverage, CAA and DNS assumptions, renewal owner, deployment targets, and alert route while there is still time to fix surprises.
- List every public hostname covered by the certificate, including apex, www, API, docs, checkout, identity, CDN, and client domains.
- Confirm whether wildcard coverage is enough or whether named SANs are required.
- Check the current issuer, serial, fingerprint, and expiry date so you can compare after deployment.
- Confirm the renewal owner and the person who can deploy or reload the certificate.
- Check whether the alert channel is still active before the final week.
| Phase | Checklist focus | Do not close until |
|---|---|---|
| Before | Scope, SANs, owner, deployment targets, alert route, and current fingerprint. | Every hostname and termination point is known. |
| During | Issuance, CDN, load balancer, ingress, web server, vendor, and service reload. | Every TLS termination point has the new certificate or active status. |
| After | Public SNI check, validity, SAN coverage, chain, fingerprint, and monitor event. | The public endpoint serves the expected certificate. |
| Failed automation | Timer, ACME logs, DNS or HTTP challenge, API credentials, deploy hooks, and reload hooks. | The automation failure cause is fixed, not only bypassed manually. |
During renewal: deploy to every TLS termination point
A certificate can be valid and still not reach users. Many environments terminate TLS in more than one place: CDN edge, load balancer, ingress, web server, appliance, partner portal, backup node, or managed hosting panel.
| Target | Question to ask | Risk if skipped |
|---|---|---|
| CDN or edge | Does the edge certificate cover the hostname and show active status? | Users may see a CDN error or a certificate that differs from origin. |
| Load balancer | Was the new certificate bound to every listener or VIP? | Some requests may still receive the old certificate. |
| Web server | Did the service reload after files changed? | The server may keep serving the old certificate from memory. |
| Ingress or Kubernetes | Did the secret update and did the controller pick it up? | The desired state may update while the public endpoint stays stale. |
| Client or vendor platform | Does the vendor need the new certificate or validation step? | The team may renew internally but leave a third-party hostname broken. |
Reload services deliberately
Copying certificate files is not deployment. Test configuration first, then reload the service that terminates TLS. If a reload fails, the old certificate may continue to serve until it expires.
Managed platforms, CDNs, and load balancers have their own activation behavior. Use their dashboard or API status instead of assuming a local reload changed the public endpoint.
nginx -t && systemctl reload nginx
apachectl configtest && systemctl reload apache2
systemctl reload haproxy
postfix reloadAfter renewal: verify from the outside
The post-renewal check should prove what users receive. Compare the new public result with the baseline captured before renewal: validity dates, issuer, SANs, serial, fingerprint, and trust-chain state.
- Check the public hostname with SNI, not only the certificate file on disk.
- Confirm the expiry date moved forward and the certificate is already valid.
- Confirm the hostname appears in SANs, including www and multi-level subdomains when needed.
- Confirm the chain validates and expected intermediates are served.
- Confirm monitoring detected the new fingerprint or certificate-change event.
HOST=checkout.example.com
openssl s_client -connect $HOST:443 -servername $HOST -showcerts </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates -serial -fingerprint -sha256If auto-renewal failed, fix the cause before closing
Do not stop at renewing manually. If automation failed once, it can fail again. Check the renewal timer, logs, DNS or HTTP challenge path, DNS provider API credentials, firewall rules, CAA records, deploy hooks, service reload hooks, and platform-specific renewal status.
- For Certbot, check the timer or cron entry and recent renewal logs.
- For DNS-01, verify the DNS provider API token, zone access, and propagation behavior.
- For HTTP-01, verify port 80 routing, redirects, firewall rules, and challenge path handling.
- For managed platforms, confirm the certificate status and whether a validation step is pending.
- Add an external expiry monitor so the next automation failure is visible before users are affected.
Where Domain Trust Watch fits
Domain Trust Watch helps with the parts teams often forget after a successful issuance: public verification, certificate-change history, expiry thresholds, owner-visible inventory, and alert delivery evidence.
- Run the free checker immediately after renewal to verify the public hostname.
- Monitor production and client hostnames so future renewal windows create visible work.
- Use certificate-change events as a post-renewal review signal instead of treating every change as noise.