How to Fix SSL Certificate Errors
Use this page when the SSL Certificate Checker shows trust failures, expiry risk, or chain problems and you need a clean production remediation path.
What This Means
SSL certificate errors usually mean the certificate is expired, the hostname does not match, the chain is incomplete, or the wrong edge layer is serving the wrong file. The fix is not just replacing a certificate. You need to confirm which layer is presenting the bad chain on the public hostname.
| Signal | What to verify | Why it matters |
|---|---|---|
| Expiry | Certificate validity window and renewal job status | Expired certs cause immediate browser trust failure. |
| Hostname mismatch | CN and SAN coverage for the live hostname | Trust fails even with a valid cert if coverage is wrong. |
| Chain trust | Intermediate bundle presentation at the edge | Missing intermediates create inconsistent browser trust. |
| Serving layer | CDN, load balancer, or origin ownership | The wrong layer may still present the old certificate. |
Common Causes
Patterns worth checking first
- Renewal drift: Automation exists but failed after DNS, ACME, or permissions changed.
- Wrong certificate bound: A CDN, proxy, or load balancer still points at an older certificate pair.
- Incomplete chain: The edge serves the leaf cert without the needed intermediates.
How To Confirm It Safely
Confirmation steps
- Check the live hostname from the public edge, not only the origin server.
- Confirm the exact hostname users reach, including www and alternate subdomains.
- Inspect the certificate chain returned by the public endpoint.
- Review expiry timing and the real renewal path before replacing files.
Fix Workflow
- Identify the serving layer. Determine whether the problem lives at origin, CDN, or load balancer.
- Replace the leaf and chain together. Upload the correct bundle rather than swapping only one file.
- Validate hostname coverage. Confirm the SAN list includes every public host tied to the route.
- Retest the public edge. Run the checker again and confirm trust, expiry, and chain details.
Implementation Examples
openssl s_client -connect example.com:443 -servername example.com -showcertsRollout Risks
A healthy origin does not guarantee the CDN is fixed
CDNs and edge proxies often terminate TLS separately from the origin.
- Retest the public hostname through the same route users hit.
- Check whether regional or cached edge behavior still serves the old certificate.
Renewal fixes can still leave hostname mismatch behind
A renewed certificate that omits the right SANs still fails production traffic.
- Validate alternate hosts too.
- Review redirect hostnames before closing the issue.
Validation Checklist
Post-fix validation
- The live hostname presents the intended certificate and chain.
- Expiry dates match the newly issued certificate, not the old one.
- No hostname mismatch remains for the public domain or critical alternates.
- The SSL Certificate Checker confirms the expected trust posture.
FAQ
Should I replace only the leaf certificate?
Not unless you are certain the intermediate bundle is already correct.
- Most production fixes are safer when the full bundle is updated together.
- Retest chain presentation after the change.
Can a CDN hide the real certificate problem?
Yes. The origin can be healthy while the public edge still serves an older or different certificate.
- Check CDN and proxy bindings separately.
- Always validate the public route users actually reach.