Fix ERR_SSL_VERSION_OR_CIPHER_MISMATCH

ERR_SSL_VERSION_OR_CIPHER_MISMATCH means the browser and the server compared their lists of supported TLS versions and cipher suites and found no overlap, so the handshake stopped before it began. Unlike most SSL errors, this one is almost always the server's fault, and almost always fixable with a few lines of configuration.

What Causes the Mismatch#

• Server limited to TLS 1.0/1.1. Every major browser removed support for these versions in 2020; a server that offers nothing newer has no version in common with a modern client.
• Obsolete cipher suites. Configs that only offer RC4, 3DES, or export-grade ciphers fail the same way even if the TLS version is acceptable.
• Hostname not covered by the certificate at the edge. On shared platforms, a certificate that does not cover the exact name being requested can surface as this error. The classic case is a wildcard: *.example.com covers app.example.com but not dev.app.example.com; wildcards match one level only.
• SNI misconfiguration. If the server picks the wrong virtual host because the client's SNI name has no matching config, the offered certificate and parameters can mismatch.
• An old appliance terminating TLS. Legacy load balancers and middleboxes that have not been updated in years cap the supported protocol versions for everything behind them.

Diagnose It#

Probe specific versions directly:

openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

A successful connection prints the negotiated protocol and cipher; a failure at both probes confirms the server offers nothing modern. SSL Labs' server test reports the same as a per-version grid, plus the full cipher list.

Fix the Server Config#

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

Apache equivalent:

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

If TLS terminates at a load balancer or CDN, the fix belongs there, not on the origin: update the security policy (AWS ALB), the minimum TLS version setting (Cloudflare), or the equivalent on your edge. For wildcard-depth problems, issue a certificate that names the host explicitly or covers the right level.

The quick-reference card: /community/errors/ssl/err-ssl-version-or-cipher-mismatch.

Limitations to Know#

• Raising the floor cuts off ancient clients. Dropping TLS 1.0/1.1 is correct, but devices stuck on old Android or embedded firmware lose access; know your traffic before you grieve for them.
• Mismatch can be version-specific. A server can pass TLS 1.2 probes yet fail 1.3-only clients with a broken 1.3 config; test both, not either.

Conclusion#

This error is a negotiation with no common ground: the server offers only deprecated TLS versions or ciphers, or presents a certificate that does not cover the requested name. Modern protocols plus a current cipher list fixes the overwhelming majority of cases.

A TLS config change is also exactly when this error appears in production, minutes after a deploy that "only touched the load balancer." An ObserveOne check against your HTTPS endpoint fails on the first broken handshake after the change, which beats finding out when the support tickets arrive.