Fix SSL Certificate Errors — Hostname, Chain & Expiry

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.

A renewed certificate that omits the right SANs still fails production traffic.

• Validate alternate hosts too.
• Review redirect hostnames before closing the issue.

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.

That warning means the browser cannot establish trusted HTTPS to the hostname you opened.

• Common causes include expired certificates, hostname mismatches, and incomplete intermediate chains.
• Start by checking the live public hostname—not a private origin IP or staging URL.

This error means the certificate is expired or not yet valid for the current date.

• Renew or reissue the certificate, then upload the new leaf and full chain to the serving layer.
• Confirm automated renewal jobs and DNS/ACME permissions still work after the fix.

The certificate SAN list does not include the hostname in the browser address bar.

• Reissue the certificate with correct CN and SAN entries for www, apex, and any alternate hosts.
• Check redirects that send users to a host not covered by the certificate.

Let's Encrypt certificates expire every 90 days. If auto-renewal broke, the most common causes are DNS changes, ACME challenge path misconfigurations, and permission issues on the renewal script.

• Run `certbot renew --dry-run` to test renewal without issuing a certificate and identify the failure reason.
• Check that the ACME challenge path (/.well-known/acme-challenge/) is publicly reachable on port 80.
• After renewal, reload or restart the web server so it picks up the new certificate files.
• Confirm the new expiry with the SSL checker — the old certificate can remain cached at a CDN edge even after the origin is updated.

ERR_SSL_PROTOCOL_ERROR means the TLS handshake failed before the certificate was even presented. This is usually a server configuration problem, not a certificate problem.

• Check that the server supports TLS 1.2 or TLS 1.3 — older TLS 1.0 and 1.1 are disabled in modern browsers.
• Verify the server is listening on port 443 and that no firewall is blocking the connection.
• If the error appears only in one browser, clear SSL state in browser settings and retry.
• Use the TLS Deep Analysis tool to inspect cipher suite and protocol support from the public edge.

The server presents the leaf certificate without the required intermediate certificates.

• Install the full chain bundle from your CA at the TLS termination layer.
• Retest with openssl s_client or the Vulnify SSL checker from outside your network.

PartialChain means the client received the leaf certificate but could not build a trusted path to a root CA — usually because intermediate certificates are missing from the server response.

• Download the full chain bundle (leaf plus intermediates) from your certificate authority — not just the .crt file.
• Install the complete bundle at every TLS termination point: origin web server, load balancer, and CDN edge.
• Retest with openssl s_client -showcerts or the Vulnify SSL checker from a network outside your infrastructure.
• If the error appears only on mobile or one browser, clear local trust caches after confirming the public edge serves the full chain.

A wrong-hostname SSL error (NET::ERR_CERT_COMMON_NAME_INVALID) means the certificate does not list the hostname users access in its Subject Alternative Names.

• Reissue the certificate with correct CN and SAN entries for apex, www, and any redirect targets.
• Check CDN and load balancer bindings — they may still serve an older certificate for that hostname.
• Verify redirects do not send users to a host not covered by the certificate.
• Retest the live public URL with the Vulnify SSL checker after rebinding the new certificate.

No. Bypassing an SSL warning means accepting an untrusted or invalid connection. Data sent over that connection is not protected by a valid certificate.

• Attackers on the same network can intercept traffic when TLS is bypassed — this is a real risk on public Wi-Fi.
• The only safe response to an SSL error on a production site is to fix the certificate, not bypass the warning.
• If you are debugging locally and see this on localhost or a staging URL, that is expected — use a self-signed cert in your dev environment.

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.

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.