Fix SSL Certificate Errors | Hostname, Chain, and Expiry
Fix SSL certificate errors for hostname, chain, and expiry when browsers show 'Your connection is not private', NET::ERR_CERT_*, or 'SSL certificate cannot be trusted' (51192). Wrong-hostname errors happen when the certificate SAN list does not cover the domain users type. Partial chain errors mean the server presents the leaf without required intermediates. Expiry errors mean the validity window has passed. This guide identifies which error you have, applies the matching fix, and shows how to verify HTTPS on the live public endpoint with the free SSL checker — no signup.
What This Means
SSL certificate errors fall into four categories, each requiring a different fix. (1) Expired certificate (NET::ERR_CERT_DATE_INVALID): the validity window has passed — renew and deploy the full leaf-plus-chain bundle, then confirm automated renewal is working. (2) Hostname mismatch (NET::ERR_CERT_COMMON_NAME_INVALID): the certificate Subject Alternative Name list does not cover the domain users are accessing — reissue with correct SAN entries including www, apex, and any redirect targets. (3) Broken certificate chain (NET::ERR_CERT_AUTHORITY_INVALID): the server presents the leaf certificate without the required intermediate certificates — install the complete CA-provided bundle at every TLS termination layer. (4) Serving layer mismatch: a CDN, proxy, or load balancer continues presenting an old certificate after the origin is updated — rebind the new certificate at each TLS-terminating edge. Always test against the live public hostname, not a private origin IP, to see the exact error your users are experiencing.
| 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 -showcerts# Use fullchain.pem (leaf + intermediates), not the leaf file alone
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# After renew or reissue, reload so every public hostname presents the new bundle
# nginx -t && nginx -s reloadSSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
# Older Apache: also set SSLCertificateChainFile to the CA intermediate bundleRollout 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.
Frequently Asked Questions
Chrome shows 'Your connection is not private' (NET::ERR_CERT_AUTHORITY_INVALID or similar) when the TLS certificate cannot be verified. The fix depends on the specific error code shown. If the error is NET::ERR_CERT_DATE_INVALID, the certificate has expired — renew and redeploy the full chain. If the error is NET::ERR_CERT_COMMON_NAME_INVALID, the certificate does not cover the hostname — reissue with the correct SAN entries. If the error is NET::ERR_CERT_AUTHORITY_INVALID, the CA is not trusted or the intermediate chain is missing — install the full bundle from your CA. Always test against the live public hostname, not localhost or a private IP, to see the same error your users see.