"ERR_SSL_VERSION_OR_CIPHER_MISMATCH" means the browser and the server couldn't agree on a TLS version or cipher, so no secure connection could be set up. Either the server only offers protocols and ciphers that browsers have retired (TLS 1.0 and 1.1, RC4, 3DES), or it has no certificate for the hostname at all and gives up mid-handshake. On Cloudflare and other CDNs, the second is the usual cause: the hostname isn't covered by an edge certificate yet. The fix is to enable TLS 1.2 and 1.3 with modern ciphers, or to get a certificate in place for the hostname.
What It Looks Like
# Chrome / Edge
This site can't provide a secure connection
www.example.com uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
# Firefox
SSL_ERROR_NO_CYPHER_OVERLAP (no cipher in common)
SSL_ERROR_UNSUPPORTED_VERSION (no TLS version in common)
# curl / OpenSSL
curl: (35) OpenSSL/3.0.13: error:0A00042E:SSL routines::tlsv1 alert protocol version
curl: (35) OpenSSL/3.0.13: error:0A000410:SSL routines::sslv3 alert handshake failureDespite the wording, "unsupported protocol" doesn't always mean an old TLS version. Chrome shows the same code when the server can't present a certificate for the name, so check both causes.
Why It Happens
1. The server only supports TLS 1.0 or 1.1
Chrome, Edge, Firefox and Safari stopped accepting TLS 1.0 and 1.1 in 2020. A server that never enabled TLS 1.2 now has no version in common with any current browser. This is typical of old appliances, embedded web interfaces, legacy Windows Server and long-unpatched hosting.
2. Only obsolete ciphers are enabled
The server speaks TLS 1.2 but only with ciphers browsers have removed, such as RC4, 3DES or export ciphers, often the result of a cipher list copied years ago and never revisited.
3. No certificate for the hostname on a CDN
Cloudflare and similar CDNs terminate TLS at their edge with a certificate for your hostname. If none exists yet, the edge can't complete the handshake. This happens on a newly added domain before its edge certificate is issued, and on hostnames deeper than one level, such as dev.api.example.com, which Cloudflare's free Universal SSL doesn't cover.
4. A certificate or key problem on the server
A virtual host that listens on 443 but has no usable certificate (a missing file, or a key that doesn't match) can also fail the handshake this way on some servers.
5. The client is the outdated one
Rarely, the server is modern and the client isn't: an old operating system or embedded device that can't speak TLS 1.2 fails against a server that, correctly, no longer offers 1.0 or 1.1.
How to Diagnose It
Try each TLS version on its own and see which the server accepts:
# Does the server accept TLS 1.2? TLS 1.3?
openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_2 </dev/null 2>&1 | grep -E "Protocol|Cipher|alert"
openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_3 </dev/null 2>&1 | grep -E "Protocol|Cipher|alert"
# Accepted: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256
# Refused: ...tlsv1 alert protocol version / handshake failure
# Full list of versions and ciphers (if nmap is installed)
nmap --script ssl-enum-ciphers -p 443 www.example.comIf TLS 1.2 and 1.3 are both refused for every hostname, the server needs updating (Fix A). If they work for other names but this one fails, check its certificate (Fix B).
How to Fix It
Fix A — Enable TLS 1.2 and 1.3 with modern ciphers
Allow only TLS 1.2 and 1.3, with an up-to-date cipher list. The ciphers below follow Mozilla's "intermediate" recommendation, which works with every current browser:
# 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:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
# 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:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder offTLS 1.3 needs OpenSSL 1.1.1 or newer. On a much older system, upgrade the OS or OpenSSL package; on Windows Server, enable TLS 1.2 for Schannel and disable 1.0 and 1.1. Reload the server after changing its configuration.
Fix B — Get a certificate in place for the hostname
On Cloudflare, open SSL/TLS → Edge Certificates and check the hostname is covered and the certificate is active. For a name deeper than one level, order an Advanced Certificate that lists it, or move the service to a one-level hostname. On your own server, make sure the virtual host for the name has a certificate and a matching key:
# Does the key match the certificate? The two hashes must be identical.
openssl x509 -noout -pubkey -in fullchain.pem | sha256sum
openssl pkey -pubout -in privkey.pem | sha256sum
# Test the configuration before reloading
sudo nginx -t && sudo systemctl reload nginxFix C — Update an outdated client
If the server is modern and only one old device fails, update that device's operating system or browser. Re-enabling TLS 1.0 on the server to suit it weakens the site for everyone else.
Verify the Fix
TLS 1.2 and 1.3 should now succeed and TLS 1.0 and 1.1 should be refused. Then reload the page in a current browser:
for v in tls1 tls1_1 tls1_2 tls1_3; do
printf "%-7s " $v
openssl s_client -connect www.example.com:443 -servername www.example.com -$v </dev/null >/dev/null 2>&1 \
&& echo accepted || echo refused
done
# tls1 refused
# tls1_1 refused
# tls1_2 accepted
# tls1_3 acceptedNewer OpenSSL builds can't test TLS 1.0 or 1.1 at all and will report them as refused either way, which is the result you want.
Frequently Asked Questions
1. The site worked for years. Why did this error appear?
Browsers removed support for TLS 1.0 and 1.1 in 2020, and dropped old ciphers such as RC4 and 3DES before that. A server that was never updated kept offering only those, so newer browsers now have nothing in common with it. Enable TLS 1.2 and 1.3 and it works again.
2. Why does only one subdomain fail on Cloudflare?
Cloudflare’s free Universal SSL certificate covers the apex and one level of subdomains (example.com, *.example.com). A deeper name like dev.api.example.com has no edge certificate, so Cloudflare can’t complete the handshake and Chrome reports this error. Order an Advanced Certificate for that name, or use a one-level hostname.
3. I just added my domain to Cloudflare. Will the error go away by itself?
Usually, yes. The edge certificate is issued after the zone becomes active, which normally takes minutes but can take up to a day. Until it exists, proxied hostnames show this error. Check the Edge Certificates page in the SSL/TLS section for its status.
4. Is it safe to re-enable TLS 1.0 for an old client?
Not on a public site. TLS 1.0 and 1.1 have known weaknesses and modern browsers refuse them anyway, so re-enabling them only helps the old client. Upgrade the client, or serve it from a separate, isolated endpoint if it truly can’t be updated.
5. Does clearing the browser cache or SSL state help?
Rarely. This error comes from what the server offers, not from anything stored in the browser, so clearing the cache only helps if an old, broken response was cached by an extension or proxy. Test the server with the TLS Checker instead.
6. Firefox says SSL_ERROR_NO_CYPHER_OVERLAP. Is that the same problem?
Yes. Firefox reports a cipher mismatch as SSL_ERROR_NO_CYPHER_OVERLAP and an unsupported protocol as SSL_ERROR_UNSUPPORTED_VERSION. Chrome folds both into ERR_SSL_VERSION_OR_CIPHER_MISMATCH. The causes and fixes are the same.