ERR_SSL_VERSION_OR_CIPHER_MISMATCH

The short version: Your browser offers only modern TLS (1.2 and 1.3) with strong ciphers. The server offers only deprecated protocols (SSL 3.0, TLS 1.0 or 1.1) or weak ciphers (RC4, 3DES). Nothing overlaps, so the handshake is aborted. To fix it for good, enable TLS 1.2 and 1.3 with a modern cipher suite on the server.

Key takeaways

• This error means the ClientHello and ServerHello found no overlap: there is no TLS version both sides allow, or no cipher suite both sides allow, so the handshake aborts before any certificate is validated.
• Far more often it is a deprecation problem, not a certificate problem. A server pinned to TLS 1.0/1.1 or a weak cipher keeps working with old tools, then breaks silently for updated browsers on the day the deprecation lands.
• The fix that lasts is on the server: offer TLS 1.2 and 1.3 with a modern cipher suite (the Mozilla Intermediate profile), and strip out SSL 3.0, TLS 1.0, TLS 1.1, RC4, and 3DES.
• On a CDN such as Cloudflare the same code shows up for an entirely different reason: an unissued edge certificate, a DNS-only record, or a multi-level subdomain the certificate does not cover.
• A valid, in-date certificate can still trigger this, which is why ordinary expiry reminders miss it completely. Only an external check that runs a full TLS handshake catches it.

Error type

SSL/TLS error

Whose side

Either

Fix difficulty

Moderate

Common cause

Browser and server share no common TLS version or cipher suite

What does ERR_SSL_VERSION_OR_CIPHER_MISMATCH mean?

Every TLS connection opens with a handshake. The browser sends a ClientHello listing every protocol version and cipher suite it will accept, and the server answers with a ServerHello that picks one combination from that list. ERR_SSL_VERSION_OR_CIPHER_MISMATCH means the intersection came up empty. No protocol version both sides allow, or no cipher suite both sides allow, so one side aborts before a certificate is even validated.

Here is the part worth holding onto: this is a deprecation problem far more often than a broken-certificate problem. When a browser vendor retires TLS 1.0/1.1 or a weak cipher, the change is invisible to everyone except the clients and servers still stuck on the old setting. A server hard-pinned to TLS 1.0 keeps answering curl, old scripts, and a few IoT devices, so monitoring that only asks 'is the certificate valid and not expired' stays green. The first warning you get is real visitors on up-to-date Chrome who suddenly cannot load the website, even though the certificate is perfectly fine.

Two other errors get mixed up with this one, so separate them now. A missing intermediate certificate throws a chain or authority error (the cert is trusted, the path is incomplete) and usually still completes the handshake. A cipher or version mismatch runs deeper: the encrypted channel never forms, so the browser never reaches the point of inspecting the certificate chain. See 'no peer certificate available' next to a handshake failure in openssl and you are looking at a negotiation problem, not a trust problem.

CDNs like Cloudflare throw the same error for a different reason entirely: a brand new domain whose Universal SSL certificate has not finished issuing, a DNS record left on 'DNS only' instead of proxied, or a multi-level subdomain such as test.dev.example.com that the wildcard certificate never covered. The edge has no certificate to present for that exact hostname, the handshake fails, and the browser reports it with the same code.

March 2020

Chrome 84 began blocking TLS 1.0 and 1.1, completing removal that year

Chrome 48

Version that dropped the RC4 cipher suite entirely

TLS 1.2 + 1.3

The only protocol versions all current browsers will negotiate

How the ERR_SSL_VERSION_OR_CIPHER_MISMATCH error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

This site can't provide a secure connection

example.com uses an unsupported protocol. The client and server don't support a common SSL protocol version or cipher suite.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

• ERR_SSL_VERSION_OR_CIPHER_MISMATCH Chrome, Edge, Brave and other Chromium browsers
• This site can't provide a secure connection the headline Chrome shows above the error code
• The client and server don't support a common SSL protocol version or cipher suite the explanatory sub-line on the error page
• example.com uses an unsupported protocol wording Chrome shows when only old TLS is offered
• SSL_ERROR_NO_CYPHER_OVERLAP the equivalent Firefox error for the same handshake failure

ERR_SSL_VERSION_OR_CIPHER_MISMATCH vs related SSL errors

Several SSL errors look similar but fail at different stages of the connection. Knowing which one you have points you straight at the fix.

TLS version support timeline

Knowing when each version was published and when browsers dropped it explains why a server can break without any change of its own.

Protocol and cipher checklist for the server

Work through these on the host serving the error; each line is something the handshake needs in order to find common ground with a current browser.

What causes ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

• The server offers only deprecated protocols, SSL 3.0, TLS 1.0 or TLS 1.1, all of which every current browser has switched off.
• Its cipher suites are weak or legacy: RC4, 3DES, or NULL ciphers. Modern browsers will not negotiate any of them.
• No SSL/TLS is configured on the requested hostname at all, so port 443 has nothing valid to present.
• SNI is missing or mismatched, so a shared IP hands back the wrong virtual host and, with it, the wrong certificate.
• On a CDN like Cloudflare, the certificate is still provisioning, the record is unproxied, or a multi-level subdomain falls outside what the certificate covers.
• The cause is local: an outdated browser or OS without TLS 1.2, a corrupted SSL state cache, or antivirus/proxy software intercepting TLS with stale settings.

How to find the cause fast

1. Start on a second device and a different network. Errors that follow you everywhere point at the server; an error on one machine alone points at that client's browser, clock, or antivirus.
2. Run the free Qualys SSL Labs test (ssllabs.com/ssltest) against the hostname. It lists every protocol version and cipher suite the server accepts and flags whatever browsers reject, which usually surfaces the problem in seconds.
3. Probe directly with openssl s_client: openssl s_client -connect example.com:443 -servername example.com. A 'sslv3 alert handshake failure' or 'no peer certificate available' tells you this is a version or cipher mismatch, not a trust issue.
4. Pin down the version by forcing one: add -tls1_2 or -tls1_3 to the openssl command. If only the older flag connects, the server has no modern TLS; if neither connects, no cipher overlaps at all.
5. Map the full picture with nmap: nmap --script ssl-enum-ciphers -p 443 example.com lists every suite per TLS version, so you can see precisely what the server offers and what it does not.

Terminal

openssl s_client -connect example.com:443 -servername example.com140735.. error:0A000410:SSL routines::sslv3 alert handshake failureno peer certificate available# No shared protocol or cipher, so the handshake fails before any certificate is sent

How ERR_SSL_VERSION_OR_CIPHER_MISMATCH looks from the outside

From the outside, a TLS version or cipher mismatch reads as a hard connection failure on port 443: the TCP socket opens, the handshake starts, then it is aborted with no HTTP response. A Pulsetic HTTPS or SSL check hitting the website from any of its 15+ global locations catches this right away, because the monitor negotiates TLS the same way a real browser does and fails the handshake exactly as Chrome does. You can run that check as often as every 30 seconds and get alerted within seconds by email, SMS, voice call, Slack, Discord, Telegram, or webhook. Pulsetic's SSL certificate monitoring also watches the certificate itself and warns you ahead of expiry, but keep in mind that expiry and a cipher mismatch are separate problems: a valid, non-expired certificate can still produce this error when the protocol or cipher list is wrong.

How to fix ERR_SSL_VERSION_OR_CIPHER_MISMATCH

For visitors

1. Rule out your own machine first. Open the website on your phone over mobile data; if it loads there, the problem is local to your computer.
2. Update your browser to the latest version so it speaks TLS 1.2 and 1.3, then restart it fully.
3. Clear the SSL state cache. On Windows: Win+R, run inetcpl.cpl, open the Content tab, click Clear SSL state. On any OS, clearing the browser cache helps too.
4. Open chrome://flags, set Experimental QUIC protocol to Disabled, and relaunch Chrome, since a QUIC glitch can show up as this error.
5. Turn off HTTPS scanning in your antivirus or any TLS-inspecting proxy for a moment; either can hand the browser its own outdated cipher set.

For website owners

1. Point SSL Labs and openssl at the hostname to see exactly which protocols and ciphers the server offers right now.
2. Turn on TLS 1.2 and TLS 1.3 in the web server config, and disable SSL 3.0, TLS 1.0, and TLS 1.1.
3. Swap any legacy cipher list for a modern one. The Mozilla Intermediate suite reaches nearly every client from the last several years; drop RC4 and 3DES.
4. Verify the certificate matches the exact hostname, www and any subdomain included, and that the full chain (leaf plus intermediates) is installed.
5. On a CDN, check that the edge certificate has finished issuing, the DNS record is proxied, and multi-level subdomains have an appropriate certificate.
6. Reload the web server, re-test, then watch from outside to confirm real clients now complete the handshake.

Browser

1. Update to the current release so TLS 1.2 and 1.3 are available.
2. Clear the SSL state and browser cache, then restart the browser.
3. Disable Experimental QUIC in chrome://flags if the error sticks around.

Nginx

1. Set ssl_protocols TLSv1.2 TLSv1.3; to drop the deprecated versions.
2. Apply the Mozilla Intermediate ssl_ciphers list and set ssl_prefer_server_ciphers off;.
3. Validate with nginx -t, then reload using systemctl reload nginx.

Apache

1. Set SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 in the SSL vhost.
2. Point SSLCipherSuite at a modern list and add SSLHonorCipherOrder off.
3. Check it with apachectl configtest, then reload via systemctl reload apache2 or httpd.

Cloudflare

1. In SSL/TLS > Edge Certificates, confirm the Universal SSL certificate shows Active.
2. Set the DNS record to Proxied (orange cloud), not DNS only.
3. For multi-level subdomains, enable Total TLS or add an Advanced/Custom certificate that covers them.

Still not fixed? Next steps

• A TLS 1.3-only client still failing after you turned on 1.3? Check that the cipher suite list really contains a TLS 1.3 suite such as AES-GCM or ChaCha20-Poly1305. Plenty of configs enable the protocol yet leave only 1.2 ciphers behind.
• When only legacy clients break after you harden the server (older IoT firmware, embedded devices, old payment terminals), make a deliberate call about supporting them. Re-adding TLS 1.0/1.1 weakens security for everyone, so isolating those clients behind a separate endpoint usually beats downgrading the main one.
• Mutual TLS endpoints can fail with this code when the browser sends no client certificate. Confirm whether client-certificate authentication is required there and that the browser actually has the right certificate installed.
• A change that looks correct but produces no live difference usually means you are editing a file the server never loads, or you forgot to reload. Validate with nginx -t or apachectl configtest, confirm the active vhost, then reload and re-test from outside.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Test the handshake with openssl

# Probe what the server negotiates (SNI included)
openssl s_client -connect example.com:443 -servername example.com

# Force TLS 1.2, then TLS 1.3, to see which versions work
openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

# List every protocol and cipher the server offers
nmap --script ssl-enum-ciphers -p 443 example.com

# Verbose curl will also surface the negotiated TLS version and cipher
curl -v https://example.com/

Nginx: modern protocols and ciphers (Mozilla Intermediate)

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;
ssl_prefer_server_ciphers off;

# Validate and apply
# nginx -t && systemctl reload nginx

Apache: disable old protocols and weak ciphers

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
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
SSLHonorCipherOrder off

# Validate and apply
# apachectl configtest && systemctl reload apache2

How to prevent ERR_SSL_VERSION_OR_CIPHER_MISMATCH

The defense that holds up is keeping server TLS settings current and catching the moment they stop working for real browsers. Adopt a maintained baseline such as the Mozilla Intermediate profile, schedule a recurring SSL Labs re-test, and disable old protocols and ciphers the moment they are deprecated instead of waiting for complaints to roll in. A cipher or version mismatch leaves the certificate looking perfectly healthy, so normal expiry reminders never see it; an external check that runs a full TLS handshake does. Pulsetic monitors HTTPS endpoints and SSL certificates from 15+ locations at intervals as short as 30 seconds, so when a config change or a browser deprecation breaks the handshake, the monitor tells you before your visitors do.

Learn how Pulsetic's SSL certificate monitoring detects this from the outside, across 15+ locations.