Browser errors
ERR_SSL_VERSION_OR_CIPHER_MISMATCH: causes and server fixes
ERR_SSL_VERSION_OR_CIPHER_MISMATCHERR_SSL_VERSION_OR_CIPHER_MISMATCH means your browser and the server have no TLS version or cipher suite in common, so no secure connection could start. It is nearly always a server or CDN configuration problem: outdated TLS settings, or no certificate available for the hostname you requested.
Is it the site or your device?
Usually the site: its TLS settings are outdated or it has no certificate for the name. Check the server's supported protocols from outside with the SSL checker:
curl ssl.sh/example.com
- The checker shows only TLS 1.0/1.1, weak ciphers, or no certificate for the name: the site must fix it. Visitors cannot safely work around it.
- The checker shows TLS 1.2/1.3 working: look locally. An outdated browser, an operating system with TLS 1.2 disabled in policy, antivirus HTTPS scanning, or a corporate proxy can cause the mismatch.
Causes
1. Server supports only TLS 1.0 or 1.1
Old appliances, legacy IIS on Windows Server 2008 and hand-tuned configs often never added TLS 1.2. Confirm:
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null
If both fail, enable TLS 1.2 and 1.3. See also NET::ERR_SSL_OBSOLETE_VERSION.
2. CDN or host has no certificate for the hostname
When a CDN edge receives an SNI name it has no certificate for, it may abort the handshake, which Chrome reports as this error. Common after adding a new subdomain, or with two-level subdomains not covered by a wildcard. Provision a certificate for that exact name.
3. Only obsolete cipher suites enabled
Servers offering only RC4, 3DES or export ciphers share nothing with modern browsers. Look up any suite with the cipher suite lookup and replace the list with a current one.
4. Certificate type and ciphers do not match
An ECDSA certificate with only ECDHE-RSA-* ciphers enabled (or the reverse) leaves no usable suite. Include both families or use the defaults of a modern OpenSSL.
5. Client-side TLS restrictions
Group Policy or registry settings that disable TLS 1.2 on Windows, old browsers, or security software can all block negotiation. Update the browser and check the TLS settings described in the Microsoft registry documentation.
What it looks like in each browser
| Browser | What you see |
|---|---|
| Chrome / Edge | "This site can't provide a secure connection" with "example.com uses an unsupported protocol. ERR_SSL_VERSION_OR_CIPHER_MISMATCH" |
| Firefox | SSL_ERROR_NO_CYPHER_OVERLAP or SSL_ERROR_UNSUPPORTED_VERSION |
| Safari | Safari can't establish a secure connection |
| curl | tlsv1 alert protocol version or sslv3 alert handshake failure |
How site owners fix it
Enabling TLS 1.2 and 1.3 with modern ciphers, and attaching a certificate for every hostname, fixes it.
1. Enable TLS 1.2 and 1.3 with modern ciphers. For 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;
The TLS config generator outputs equivalent blocks for Apache, HAProxy and others.
2. On Windows Server, enable TLS 1.2 under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols as described in Microsoft's TLS registry settings, then reboot. Windows Server 2012 R2 and later support TLS 1.2 out of the box.
3. Cover every hostname. Make sure each name served through the CDN or load balancer has a certificate attached.
4. Re-test. curl ssl.sh/example.com should list TLS 1.2 and 1.3 as supported with a valid certificate.
FAQ
Can I re-enable TLS 1.0 in Chrome to reach an old device?
Not in current versions; the option was removed. For an old printer, switch or router you own, use its HTTP admin interface on a trusted local network or update its firmware. Do not downgrade browser security for websites on the internet.
The site uses a CDN and the error appeared after adding a subdomain. Why?
The CDN probably has no certificate for that hostname, so it cannot complete the handshake and aborts with a version or cipher mismatch. Issue or upload a certificate that covers the new name, including deeper subdomains like a.b.example.com.
Does this error mean the site has been hacked?
No. It is a compatibility failure, not a sign of compromise. The site is either running outdated TLS settings or is missing a certificate for the hostname.