Expired or failed TLS certificate replacement: restore HTTPS safely
Inspect the certificate actually served on the user path, then validate renewal, deployment, and CDN propagation instead of only checking a PEM file on disk.
Maintained by Kevin · Ovalk
Scope and prerequisites
HTTPS endpoints using OpenSSL 3.x for diagnostics. CDN edge certificates and origin certificates are separate deployments.
Know the hostname and TLS termination points. Inspect private-key files only on their owning host; do not copy them into tickets. Check the client's clock as well as certificate dates.
Common symptoms
- Browsers report an expired, invalid-date, or hostname certificate error.
- Monitoring still reports expiry after a renewal.
- Some locations receive a new certificate while others receive an old one.
1. Inspect the certificate served to users
Query the hostname with SNI from an external path. Record subject, issuer, serial number, and dates; the serving edge—not the file on disk—is the source of truth.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates -serial2. Validate the deployed chain
Map where TLS terminates across CDN, load balancer, proxy, and origin. Verify key and certificate match, the full chain is present, and configuration tests pass before a graceful reload.
State-changing example below — confirm authorization, scope and recovery before executing.
openssl x509 -in fullchain.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256
openssl pkey -in privkey.pem -pubout -outform DER | openssl dgst -sha256
nginx -t && systemctl reload nginx3. Repair renewal rather than bypassing validation
Do not weaken client validation or fall back to HTTP. Capture the ACME challenge failure, DNS propagation behavior, permissions, and renewal logs, then repair the automation.
journalctl -u certbot --since "24 hours ago" --no-pagerInterpret the evidence
| Observation | What to check next |
|---|---|
| Valid dates; hostname mismatch | Check subject alternative names and the requested SNI hostname. A valid certificate for another name is still invalid for this request. |
| Certificate and key public-key hashes differ | They are not the matching pair. Stop the deployment and locate the correct key securely. |
| Chain verification fails | Check intermediate certificates and the intended trust store. Certificate dates alone do not prove trust. |
Illustrative diagnosis
A hypothetical example to explain the reasoning, not a reported customer incident or a claim of testing on your stack.
The origin has a renewed certificate but visitors still see an expired one. If TLS terminates at a load balancer, renewing the origin file does not change the certificate served by the balancer. Compare served serial numbers at each termination point and deploy the renewal at the failing endpoint.
Verify recovery
- Use a normal validating HTTPS client against the public hostname. Confirm the intended hostname, chain and expiry without an insecure flag.
- Repeat against all relevant termination points and check renewal automation logs so the next renewal can complete.
Rollback and stopping point
Keep the previous working certificate/key pair until validation completes. Only restore it if still valid for the hostname. An expired old certificate is not a usable rollback; use a valid reissue or a healthy endpoint.
Prevention and long-term repair
- Alert from an external probe at 30, 14, and 7 days before expiry.
- Validate serial number and expiry after every automatic renewal.
- Maintain an inventory of every TLS termination point.
References and corrections
Use the documentation for your installed version. The references below explain the underlying behavior; commands still need environment-specific validation.
Report a correction to Kevin — include the page URL, version and a redacted reproduction. See our editorial policy.