SSL & Security Errors

About this error category

# SSL & Security Errors

SSL and security errors occur when a browser cannot establish or validate a trusted HTTPS connection. The failure may happen during the TLS handshake, when the server presents its certificate, or when the certificate does not match the hostname being visited.

The same website can show different results for its root domain, a subdomain, or its www variant. A public CDN or reverse proxy can also present a different certificate from the origin server. Start by recording the exact hostname and browser error instead of treating every SSL warning as the same problem.

Common symptoms

You may see:

• A warning that the connection is not private or secure
• A certificate name or hostname mismatch
• A connection that fails before the page loads
• ERR_SSL_PROTOCOL_ERROR or another TLS protocol message
• Different results for the root domain, a subdomain, or the www hostname
• A site that works through a CDN or proxy but fails when connecting directly to its origin

Diagnose the failure by layer

1. Record the exact hostname and error

Check the complete hostname in the address bar, including its subdomain. Compare the affected hostname with the www and non-www versions if both are in use. Also record the complete browser error, because a certificate mismatch and a failed TLS negotiation require different checks.

For a hostname mismatch, see [NET::ERR_CERT_COMMON_NAME_INVALID](/errors/err-cert-common-name-invalid). This generally means the server presented a certificate that does not cover the hostname in the address bar.

2. Inspect the certificate presented to the browser

Open the browser’s certificate details and review:

• The certificate’s Subject Alternative Names, which identify covered hostnames
• The validity dates
• The issuer and trust status
• The certificate chain
• Whether the server is presenting the expected certificate rather than a hosting provider’s default certificate

A certificate for the root domain is not automatically valid for every subdomain. The affected hostname must be covered by the certificate’s names, or by an applicable wildcard name.

If the certificate is correct in one environment but not another, investigate DNS, SNI, reverse-proxy routing, and CDN configuration. Different TLS endpoints can serve different certificates for the same apparent site.

3. Distinguish certificate validation from a TLS handshake failure

A hostname or trust warning usually means the browser reached a point where it could inspect a certificate. A protocol error can indicate that the TLS negotiation failed earlier. Check whether:

• Port 443 is serving HTTPS and TLS rather than plain HTTP
• The intended HTTPS virtual host is selected for the requested hostname
• The server’s TLS configuration is enabled and internally valid
• The certificate and private key belong together
• The complete certificate chain is installed where the server expects it
• A proxy, load balancer, firewall, or CDN is interrupting the handshake

For the protocol-specific case, see [ERR_SSL_PROTOCOL_ERROR](/errors/err-ssl-protocol-error).

4. Compare the public and origin connection paths

Determine whether the error occurs only at the public hostname, only at the origin hostname, or at both. A CDN or reverse proxy may terminate HTTPS at the public edge and use a separate TLS connection to the origin. Its certificate and TLS settings do not necessarily match the origin server’s configuration.

Also verify that DNS sends the hostname to the intended service. An old address, staging server, or shared hosting endpoint can return a certificate unrelated to the site you meant to visit.

5. Retest the exact failing hostname

After correcting one certificate binding, hostname mapping, or TLS layer, test the same hostname again. If multiple hostnames are affected, test them independently. This shows whether the issue is limited to one endpoint or reflects a wider DNS, proxy, or server configuration problem.

Avoid bypassing a browser warning as a troubleshooting method. Doing so does not correct the server configuration and may expose the connection to risk. First identify whether the problem is a hostname mismatch, an untrusted or incomplete certificate chain, or a failed TLS negotiation.

When to use the related guides

• Use [ERR_SSL_PROTOCOL_ERROR](/errors/err-ssl-protocol-error) when the browser reports that the SSL or TLS protocol could not be completed.
• Use [NET::ERR_CERT_COMMON_NAME_INVALID](/errors/err-cert-common-name-invalid) when the presented certificate does not match the hostname in the address bar.

The exact browser message, hostname, certificate details, DNS destination, and connection path are more useful than the general label “SSL error.” Capture those details before replacing certificates or changing server settings.

Further reference areas

For implementation-specific details, consult the documentation for the affected browser, web server, certificate authority, CDN or reverse proxy, and hosting platform. The relevant sections are usually named certificate installation, certificate chains, SNI or virtual hosts, TLS configuration, and origin HTTPS settings.