Fix ERR_SSL_VERSION_OR_CIPHER_MISMATCH

ERR_SSL_VERSION_OR_CIPHER_MISMATCH means the browser could not establish a usable TLS connection. An incompatible protocol or cipher configuration is one cause. On a CDN, an inactive or unavailable edge certificate for the requested hostname can produce the same error.

Start at the system that terminates the browser's TLS connection: your server, load balancer, or CDN edge. A request that fails during the handshake may never reach application code.

Find the failing connection

If several independent networks reproduce the error, inspect the server or CDN configuration first. If only one device fails, compare its browser, OS, proxy, and network path with a working client.

For a site behind a CDN, distinguish browser-to-edge TLS from edge-to-origin TLS. A Cloudflare origin problem can instead result in an HTTP 525 or 526 response after the browser has connected to the edge.

Guance HTTP tests from multiple locations can help identify which paths fail. Compare the same time window, then inspect the matching TLS termination logs.

Check the server and CDN

Run the public hostname through SSL Labs' server test if the endpoint is suitable for an external scan. Review protocol support, certificate coverage, and the chain.

At a CDN, confirm the edge certificate is active and covers the requested hostname. A newly added name or a deeper subdomain may not be covered by the existing certificate. Cloudflare documents these cases in its version or cipher mismatch guide.

Also check DNS and SNI routing. A stale IP, shared-host default virtual host, or CNAME alias missing from SAN can send the client to the wrong configuration. If the server actually presents a certificate for the wrong name, the browser typically reports NET::ERR_CERT_COMMON_NAME_INVALID; that is a different diagnosis.

For Nginx, a supported modern protocol configuration is:

ssl_protocols TLSv1.2 TLSv1.3;
# Configure cipher suites for the deployed Nginx/OpenSSL versions.
# ssl_ciphers does not configure TLS 1.3 cipher suites.

Confirm the installed TLS library supports the requested versions. Do not re-enable obsolete protocols to make the warning disappear. Missing intermediates also break HTTPS verification, but typically produce certificate trust errors; deploy a full chain and use the actual error output to distinguish failures.

Check an affected client

Update the browser and operating system. Restart Chrome fully with chrome://restart if stale process state is suspected. Windows Internet Options also exposes a Clear SSL state action, although clearing state does not repair a server's protocol configuration.

Confirm the system clock is correct. Clock errors generally produce certificate-validity errors rather than a genuine cipher mismatch.

In a managed network, ask the administrator to check the HTTPS inspection proxy's protocol support and certificate deployment. Compare against an approved alternate path when possible; disabling endpoint protection is not a TLS configuration fix.

Common questions

Why did a working site suddenly break?

Review recent DNS, TLS, CDN, and certificate activation changes. An expired certificate normally has its own browser error, but a CDN with no usable active certificate can fail before presenting one.

Why did the error start after adding a CDN?

Check the edge certificate's status and hostname coverage first, then inspect origin TLS separately. The two connections have different certificates and potentially different protocol policies.

Is this the same as COMMON_NAME_INVALID?

No. That error identifies a mismatch between the requested name and the certificate presented. A version/cipher error concerns establishing the TLS connection, including CDN cases where no suitable certificate can be selected.