ERR_SSL_VERSION_OR_CIPHER_MISMATCH - Fix

This site can't provide a secure connection example.com uses an unsupported protocol. ERR_SSL_VERSION_OR_CIPHER_MISMATCH

ERR_SSL_VERSION_OR_CIPHER_MISMATCH means the browser and the server have no TLS protocol version or cipher suite in common. The handshake ends immediately because there is nothing to negotiate.

This is the most precise of Chrome's TLS errors, and unusually one-sided: the fix is nearly always on the server.

Is This You or the Site?

Step 1: Test from outside

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>&1 | grep -E "Protocol|Cipher"

Or use our SSL/TLS checker, which reports the negotiated protocol and cipher from outside your network.

That last row is the one people misdiagnose. A cipher mismatch means both sides spoke TLS and failed to agree; if openssl s_client returns no protocol or cipher at all, nothing was negotiated, and you are looking at a plain-HTTP listener on 443 or a proxy terminating the connection rather than a cipher configuration problem.

Step 2: Enumerate what the server actually offers

This is the step that turns guesswork into a fix:

nmap --script ssl-enum-ciphers -p 443 example.com

Sample output from a server that produces this error:

| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - D
|     least strength: D

TLS 1.0 only, with a 3DES cipher. No current browser will talk to that, and no client-side setting changes it.

A healthy server looks like this:

|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|   TLSv1.3:
|     ciphers:
|       TLS_AES_256_GCM_SHA384 (ecdh_x25519) - A

Site-Owner Fixes

1. Enable TLS 1.2 and 1.3

Test each version explicitly to see what you currently support:

openssl s_client -tls1_2 -connect example.com:443 -servername example.com < /dev/null
openssl s_client -tls1_3 -connect example.com:443 -servername example.com < /dev/null

nginx:

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:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

sudo nginx -t && sudo systemctl reload nginx

Apache:

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

sudo apachectl configtest && sudo systemctl reload apache2

Those cipher lists are Mozilla's intermediate configuration - compatible with every current browser while excluding everything known to be broken. Rather than curating a list by hand, generate one from the Mozilla SSL Configuration Generator for your exact server and version.

2. Check for a restrictive cipher list

A common cause is a cipher list written years ago to satisfy an audit, never revisited, and now excluding everything modern clients offer. If ssl_ciphers names specific suites you do not recognise, replace the whole line rather than editing it.

Be careful with ! exclusions accumulated over time - a long chain of them can eliminate every remaining suite.

3. Check SNI and the default virtual host

If the requested hostname matches no server block, the server may fall back to a default whose TLS configuration is different or absent:

# With SNI
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>&1 | grep -E "Protocol|Cipher|subject="

# Without SNI - reveals the default vhost
openssl s_client -connect example.com:443 < /dev/null 2>&1 | grep -E "Protocol|Cipher|subject="

Different results mean the hostname is not matching the server block you expect. Confirm server_name covers the hostname exactly, including the www form.

4. Look at what sits in front

The server you are configuring may not be the one terminating TLS. A load balancer, WAF, CDN or hardware appliance in front holds its own TLS settings, and an old appliance is a frequent source of this error. Confirm which device answers on port 443 before spending time on the origin.

5. Certificate key type

Every current browser supports ECDSA, so this is now a rare cause - but old clients and embedded devices may only support RSA. If you must serve both, nginx accepts multiple ssl_certificate directives, one per key type, and selects the right one per client.

Visitor-Side Notes

There is no safe client-side fix, and it is worth saying plainly rather than offering something that does not work.

Worth trying:

• Another browser. TLS stacks differ slightly; a site failing in Chrome may load in Firefox, which at least confirms the server is reachable.
• A different network. A corporate proxy performing TLS inspection can narrow what is offered. Test from mobile data.
• Report it. If the site is one you need, tell its operator - they may not know it is unreachable.

Do not search for ways to re-enable TLS 1.0 or 1.1. They have known weaknesses, PCI DSS prohibits them, browsers removed the setting deliberately, and any instructions you find that still work are lowering the security of every site you visit to reach one broken server.

Verify the Fix

# Negotiated protocol and cipher
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | grep -E "Protocol|Cipher"

# Everything the server offers
nmap --script ssl-enum-ciphers -p 443 example.com

# End to end
curl -sI https://example.com | head -1

You want TLSv1.2 or TLSv1.3 negotiated, an A-graded cipher list from nmap, and an HTTP status line from curl. Load the site in a browser afterwards - a passing openssl handshake with a still-failing browser usually means a second listener or a proxy you have not found yet.

Prevention

• Generate your TLS configuration from the Mozilla SSL Configuration Generator rather than maintaining a hand-written cipher list, and regenerate it when you upgrade the server.
• Scan your own endpoints on a schedule with nmap --script ssl-enum-ciphers or an external checker. Browser deprecations arrive with notice, but only if someone is looking.
• Inventory every device that terminates TLS - origin servers, load balancers, WAFs, CDNs, appliances. The forgotten one is where this error comes from.
• Follow browser deprecation announcements. TLS 1.0 and 1.1 were removed on a published schedule, and the sites that broke were the ones nobody was tracking.
• Include a TLS version assertion in monitoring so a regression is reported rather than discovered by a visitor.