ERR_SSL_VERSION_OR_CIPHER_MISMATCH means the browser and the server found no TLS version or cipher suite they both accept, so the handshake stopped before any page loaded. It is almost always the server: TLS 1.0/1.1 only, legacy ciphers, a missing certificate for that hostname, or a CDN edge certificate that does not cover the name.
Chrome and Edge print it under the headline "This site can't provide a secure connection" with the line "example.com uses an unsupported protocol" and the detail "The client and server don't support a common SSL protocol version or cipher suite." That sentence is the whole diagnosis. This guide shows how to find out which half of it is true for your site, how to fix it in nginx, Apache, IIS and Cloudflare, and what to do when the site is an old router or server admin page you cannot reconfigure. It is written for site owners and administrators; the visitor-side checks are in their own section.
What ERR_SSL_VERSION_OR_CIPHER_MISMATCH means
When a browser opens an HTTPS connection, it sends the server a list of supported TLS versions and cipher suites in a ClientHello message. The server picks a shared option and replies with ServerHello. If there is no overlap — no common protocol version or no common cipher suite — the handshake aborts and Chrome shows ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Firefox shows SSL_ERROR_NO_CIPHER_OVERLAP; Safari shows "Safari can't establish a secure connection."
The key word is mismatch. This error is not about an expired certificate by itself or a wrong domain — it fails at the very first stage, before certificate validation. The two sides literally could not find a common language for encryption. That is also why Chrome offers no "Proceed anyway" link here: with a certificate warning there is a finished connection to click through, with a cipher mismatch there is nothing to proceed to.
The same error in Chrome, Edge, Firefox and Safari
| Browser | What you see | Error code |
|---|---|---|
| Chrome (Windows, macOS, Linux, Android) | This site can't provide a secure connection — uses an unsupported protocol | ERR_SSL_VERSION_OR_CIPHER_MISMATCH |
| Microsoft Edge | Same page as Chrome (same Chromium network stack) | ERR_SSL_VERSION_OR_CIPHER_MISMATCH |
| Firefox | Secure Connection Failed | SSL_ERROR_NO_CIPHER_OVERLAP or SSL_ERROR_UNSUPPORTED_VERSION |
| Safari (macOS, iOS) | Safari can't open the page because Safari can't establish a secure connection to the server | no code shown |
| curl / OpenSSL | sslv3 alert handshake failure, no protocols available or unsupported protocol | handshake alert 40 / 70 |
If Chrome and Edge fail but Firefox connects, do not conclude the site is fine: Firefox may simply still accept something the Chromium browsers have dropped, or the Firefox profile has a lowered minimum TLS version. Test with openssl before deciding.
Causes of ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Causes fall into two broad groups: server-side (the vast majority) and client-side. Let's cover both.
Outdated TLS versions (1.0 and 1.1)
The most common cause after 2020. Chrome, Firefox, Safari, and Edge have all disabled TLS 1.0 and TLS 1.1 as insecure. If your server is configured to speak only these protocols, a modern browser finds no common version and throws the error. The fix is to enable TLS 1.2 and TLS 1.3 on the server.
Incompatible cipher suites
Even when the TLS version matches, both sides must agree on a specific cipher suite. If the server offers only outdated ciphers (RC4, 3DES, DES, export-grade, or ciphers without forward secrecy) that browsers dropped long ago, there is no overlap. You need a modern list: ECDHE with AES-GCM and ChaCha20-Poly1305.
Weak and legacy ciphers: RC4, 3DES, DES
RC4 is prohibited in TLS (RFC 7465 bans it outright), 3DES is vulnerable to the Sweet32 attack, and export-grade ciphers are a 1990s relic. Browsers removed them from their default lists. A server relying on such ciphers is doomed to mismatch with modern clients. How to list and strip them is covered in finding and disabling weak cipher suites.
Certificate problems
Although the error is primarily about protocol and ciphers, a misconfigured certificate can also trigger it: a wrong key format, a certificate/cipher type mismatch (for example an ECDSA key with RSA-only ciphers in the config), or a self-signed or corrupted certificate that stops the server from completing negotiation. An expired certificate usually gives a different error (NET::ERR_CERT_DATE_INVALID), but combined with a restrictive config it can surface as a cipher mismatch.
No certificate for this hostname (SNI)
On a server or load balancer that hosts many HTTPS sites, the certificate is chosen by the name the browser sends in the SNI extension. If a hostname points at the machine but no server block, virtual host or listener has a certificate for it, the server has nothing to offer and aborts the handshake. Typical triggers: a new subdomain whose DNS record went live before the certificate was issued, a www name added in DNS but missing from the virtual host, or a hosting panel where HTTPS was enabled for the apex domain only. In the nginx error log this usually appears as no "ssl_certificate" is defined for the "listen ... ssl" directive or SSL_do_handshake() failed ... no shared cipher.
Cloudflare and other CDNs: the edge certificate does not cover the name
Behind a proxying CDN, the browser negotiates TLS with the CDN edge, not with your server, so the cause lives in the CDN dashboard. On Cloudflare three situations produce this exact error:
- Multi-level subdomain. The free Universal SSL certificate covers the apex and first-level subdomains (
example.com,*.example.com). A proxied record such aswww.dev.example.comis not covered, and the edge has no certificate to present. Either make the record DNS-only, or order an Advanced certificate that includes it. Cloudflare documents this in its Universal SSL limitations. - Certificate still being issued. Right after a zone is added or a record switched to Proxied, the edge certificate can be pending. Check SSL/TLS → Edge Certificates; the error clears once the status is Active.
- Minimum TLS Version set too high. Under SSL/TLS → Edge Certificates → Minimum TLS Version, a value of TLS 1.3 locks out every client that only speaks TLS 1.2, including older Android devices and many API clients.
The AWS Amplify case that tops Google for this error is the same story: Amplify expected an extra www CNAME record, the proxied name had no matching certificate, and adding the missing records fixed it. If Cloudflare instead reports a problem between its edge and your server, that is a different error — see Cloudflare 525 SSL handshake failed.
Firewalls and TLS inspection in the middle
A corporate proxy, antivirus "HTTPS scanning" or a next-generation firewall terminates TLS itself and opens a second connection to the site. If that middlebox is older than the browser, it offers a ClientHello the site rejects, or answers the browser with ciphers the browser no longer accepts. The error then appears only inside that network, on every HTTPS site with a modern configuration.
Server-side or client-side error
The first practical step is to locate the problem. If every user sees the error on every device, it is almost certainly the server. If only you see it on one device but the site loads on your phone over mobile data, the cause is local (an outdated browser, antivirus, system clock, or a corporate proxy). The table below helps you diagnose.
| Cause type | Symptom | How to check | Fix |
|---|---|---|---|
| Server: old TLS | Error for everyone, all devices | openssl s_client -connect host:443 -tls1_2 | Enable TLS 1.2/1.3 in server config |
| Server: weak ciphers | Error in new browsers, old ones work | Check on /en/ssl or SSL Labs | Set a modern ssl_ciphers list |
| Server: certificate | Handshake aborts for all | openssl s_client -connect host:443 -showcerts | Reinstall certificate and chain |
| Client: old browser | Error for one user only | Open the site in another browser/device | Update browser and OS |
| Client: antivirus/proxy | Error disappears without antivirus | Temporarily disable HTTPS scanning | Turn off SSL inspection in the software |
| Client: system clock | TLS errors on many sites | Check the system date and time | Sync the clock via NTP |
How to test which TLS versions and ciphers a server accepts
Run the tests from a machine outside your own network, and always pass -servername: without SNI, a multi-site server answers with its default certificate and you end up testing the wrong site.
# Does the server speak TLS 1.2 and TLS 1.3?
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
# Does it still speak TLS 1.0 / 1.1? (OpenSSL 3 refuses these by default,
# so lower the local security level just for this test)
openssl s_client -connect example.com:443 -servername example.com -tls1 -cipher 'DEFAULT:@SECLEVEL=0' </dev/null
# Full list of versions and cipher suites the server offers
nmap --script ssl-enum-ciphers -p 443 example.comHow to read the results:
| Output | What it means | Next step |
|---|---|---|
Protocol : TLSv1.2 plus a Cipher : line | That version works; the handshake completed | Move on to the next version or to the client side |
sslv3 alert handshake failure (alert 40) | Server rejected the offer: no shared cipher, or no certificate for this name | Check ssl_ciphers and the certificate for this hostname |
tlsv1 alert protocol version (alert 70) | Server does not support the version you forced | Normal for TLS 1.0/1.1; a problem if it happens with -tls1_2 |
no protocols available | Your local OpenSSL refuses the version, not the server | Add -cipher 'DEFAULT:@SECLEVEL=0' or test from another machine |
unexpected eof while reading / connection reset | Something closed the connection mid-handshake: firewall, wrong port, not TLS at all | Confirm the port serves HTTPS; check firewalls and load balancers |
If the server passes these tests from the outside but a particular HTTP library still fails, the library's own TLS settings (its OpenSSL build, Java version or system crypto policy) are the limit, not the server.
How to fix it on the server
If diagnosis pointed to the server, edit your web server configuration to enable current protocols and ciphers. Below are proven settings for nginx and Apache that match Mozilla's recommendations (Intermediate profile). The Mozilla SSL Configuration Generator produces the same blocks for your exact server and OpenSSL versions.
nginx configuration
In your site's server block, set the protocol versions and cipher list. TLS 1.3 cipher suites are fixed by the standard; for TLS 1.2 we specify ECDHE-first suites:
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/ssl/example.com/fullchain.pem;
ssl_certificate_key /etc/ssl/example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
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_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
}After editing, test the syntax and reload nginx:
sudo nginx -t
sudo systemctl reload nginxTwo nginx traps cause this error even with a correct cipher list. First, ssl_protocols set in several places: the effective value comes from the server block that handles the connection, and when several sites share one IP and port, the protocol list of the default server can win. Keep the directive in the http block and identical everywhere. Second, a certificate with an ECDSA key needs ECDHE-ECDSA-* suites; a list containing only ECDHE-RSA-* leaves nothing to negotiate.
Apache configuration
In your virtual host file (for example /etc/apache2/sites-enabled/example.com.conf) or the SSL config, set:
<VirtualHost *:443>
ServerName example.com
SSLEngine on
SSLCertificateFile /etc/ssl/example.com/fullchain.pem
SSLCertificateKeyFile /etc/ssl/example.com/privkey.pem
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder off
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
</VirtualHost>Validate the configuration and reload Apache:
sudo apachectl configtest
sudo systemctl reload apache2On RHEL, AlmaLinux and Rocky Linux the service is httpd and the SSL settings usually live in /etc/httpd/conf.d/ssl.conf; the system-wide crypto policy (update-crypto-policies --show) also limits what Apache and nginx may offer.
IIS and Windows Server
IIS takes its protocols and ciphers from Windows (Schannel), not from the site configuration. TLS 1.2 is controlled by the registry key HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server with Enabled = 1 and DisabledByDefault = 0; the cipher order comes from Group Policy (Computer Configuration → Administrative Templates → Network → SSL Configuration Settings → SSL Cipher Suite Order). A reboot is required after changing Schannel settings. Old servers that were hardened by removing every suite from that list are a classic source of this error.
Verify the result with openssl and curl
Confirm the server now accepts TLS 1.2 and returns a valid cipher. The openssl s_client command shows the negotiated protocol version and cipher suite:
openssl s_client -connect example.com:443 -servername example.com -tls1_2
# Look for: Protocol : TLSv1.2 and Cipher : ECDHE-RSA-AES128-GCM-SHA256For a quick check with curl and a verbose handshake log:
curl -v --tlsv1.2 https://example.com/
# The line '* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256' confirms successTo confirm the old protocols are really gone, force the maximum version down: curl -v --tls-max 1.1 https://example.com/ should now fail, while the command above succeeds.
How to fix it in the browser
If the error appears only for you while the site loads on other devices, the problem is client-side. Work through these steps in order:
- Update your browser and OS. Old versions of Chrome or Firefox, or an outdated Windows/Android, may not support modern ciphers.
- Clear the SSL state and cache. On Windows: Internet Options → Content → Clear SSL state. Restart the browser. This rarely fixes a true cipher mismatch, but it is harmless and quick.
- Check the date and time. A wrong system clock breaks TLS on many sites — sync it via NTP.
- Disable antivirus HTTPS scanning. Kaspersky, ESET, Avast, and others intercept TLS and can force incompatible ciphers.
- Check proxy and VPN software. Corporate proxies with SSL inspection are a common cause. Disable them temporarily to test, or ask the network team to update the inspection device.
- Try incognito mode. This rules out interference from browser extensions.
Important: do not try to "re-enable old TLS 1.0/1.1" in the browser as a workaround — it lowers your own security. The right fix is to correct the server.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH on Android
Chrome on Android ships its own TLS library, so on a current phone the error almost always points at the server, exactly as on desktop. The exceptions are old Android releases, where apps and in-app browsers (WebView) rely on the system TLS stack: versions before Android 5.0 do not enable TLS 1.2 by default for apps. If a site works in Chrome but fails inside an app on an old phone, the phone is the limit. Also check the date on the device — a phone that has been switched off for a long time can boot with a wrong clock.
In Discord and other Chromium-based apps
Desktop apps built on Chromium, such as Discord, show the same error code and follow the same logic. When a large service's own pages fail this way on one computer, the cause is almost always local — antivirus HTTPS scanning, a corporate proxy or a wrong clock — because the service itself supports current TLS.
Old router, NAS, iDRAC or printer admin page
A large share of the reports on Reddit and Google's help forum are not public websites at all: 192.168.1.1 router logins, Ubiquiti radios, Dell iDRAC on older PowerEdge servers, NAS boxes and printers. Their embedded web servers were built when TLS 1.0 and ciphers like 3DES were normal, and current browsers no longer speak that language. In order of preference:
- Update the firmware. Many vendors added TLS 1.2 in later releases; this is the only fix that lasts.
- Use the device's other management path — SSH, a vendor CLI such as Dell
racadm, or the vendor's mobile app. - If the vendor has abandoned the device and it sits on a trusted management network, Firefox lets you lower its own minimum version in
about:config:security.tls.version.min(1 = TLS 1.0, 3 = TLS 1.2, the default). Use a separate Firefox profile for this and never browse the internet with it.
Chrome and Edge have no equivalent switch, which answers the frequent "ERR_SSL_VERSION_OR_CIPHER_MISMATCH Chrome bypass" and "Edge bypass" searches: there is no flag that makes a modern Chromium browser accept a protocol it has removed. A device you still have to manage over TLS 1.0 is a device that should be replaced or kept off any network you care about.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH vs ERR_SSL_PROTOCOL_ERROR
The two errors are often confused and searched together. The difference tells you where to look:
| ERR_SSL_VERSION_OR_CIPHER_MISMATCH | ERR_SSL_PROTOCOL_ERROR | |
|---|---|---|
| What happened | Server answered, but no common version or cipher exists | The response was not valid TLS, or the handshake was cut off |
| Typical server cause | TLS 1.0/1.1 only, legacy ciphers, no certificate for the name | HTTP served on port 443, broken proxy config, reset by a firewall |
| Typical client cause | Very old OS or browser, outdated TLS inspection | Wrong clock, QUIC/proxy interference, faulty extension |
| First command | openssl s_client ... -tls1_2 and nmap --script ssl-enum-ciphers | curl -v https://host/ to see where the handshake dies |
The step-by-step repair for the second one is in fixing ERR_SSL_PROTOCOL_ERROR.
How to check your site's SSL
Before changing the configuration, it helps to see the full picture: which TLS versions and ciphers the server actually offers, whether the certificate chain is valid, and when it expires. Our free SSL certificate checker shows the negotiated protocol, cipher suite, validity period, and trust chain in a couple of seconds — no local utilities required. It is a fast way to confirm that ERR_SSL_VERSION_OR_CIPHER_MISMATCH is gone after your fixes.
Because it tests from outside your network, it also answers the "is it me or the server" question: if the check completes with TLS 1.2 or 1.3 and a modern cipher while your browser still fails, the problem is on your side of the connection. To see whether the site responds at all and where redirects lead, run the HTTP header checker; to catch the next change before visitors do, put the domain under SSL and uptime monitoring.
Useful related reading: fixing ERR_SSL_PROTOCOL_ERROR, why the SSL handshake fails, and a comparison of TLS 1.3 versus TLS 1.2.
FAQ
Why did this error appear suddenly on a site that used to work?
Most likely your browser updated and disabled the outdated protocol or cipher your server relied on, or a CDN setting changed. Chrome and Firefox gradually remove TLS 1.0/1.1 and weak ciphers, so a server that worked yesterday can become incompatible overnight. Update the configuration to TLS 1.2/1.3 with modern cipher suites.
Is this my server's problem or my computer's?
Check the site from another device and over mobile data. If everyone sees the error, the server is at fault: old TLS, weak ciphers or no certificate for that name. If only you see it, the cause is local — an outdated browser, antivirus with HTTPS scanning, a wrong system clock, or a corporate proxy.
How do you fix an SSL error?
Read the exact code first — each one points to a different layer. A cipher mismatch is fixed in the server's protocol and cipher settings, a date error by renewing the certificate, a name error by reissuing it for the right hostnames, and an authority error by installing the full chain. Then retest from outside your network.
Can I bypass ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Chrome or Edge?
No. Unlike certificate warnings, there is no "Proceed" link because no secure connection was ever established, and Chromium browsers have no setting to re-enable TLS 1.0/1.1. The fix has to happen on the server — or, for an abandoned device on your own network, through a firmware update or its other management tools.
Should I keep TLS 1.0 and 1.1 support for old clients?
No. TLS 1.0 and 1.1 are officially deprecated (RFC 8996) and insecure. Modern operating systems and browsers have supported TLS 1.2 for years. Configure TLS 1.2 and 1.3 — that covers all current clients without compromising security.
Does reissuing the certificate help?
Only if the original problem was the certificate itself — corrupted, wrong key format, missing for that hostname, or a type mismatch (ECDSA versus RSA). In most cases the cause is protocol and cipher settings, so fix ssl_protocols and ssl_ciphers first and keep reissuing as a last resort.
