ERR_SSL_VERSION_OR_CIPHER_MISMATCH: Fix in Chrome & Edge

What Is ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

ERR_SSL_VERSION_OR_CIPHER_MISMATCH means your browser and the website couldn't agree on how to encrypt the connection. Chrome shows "This site can't provide a secure connection" and "example.com uses an unsupported protocol"; under details, "The client and server don't support a common SSL protocol version or cipher suite." Chromium lists it as error -113 (net_error_list.h).

It happens in the very first step of the TLS handshake. Your browser sends the TLS versions and cipher suites it supports; the server has to pick one of each. If the server has nothing in common with that list, answers with a version the browser no longer accepts, or refuses to continue because it has no certificate for the name you asked for, the handshake stops right there.

Because it fails before any certificate is checked, an expired, misnamed or badly chained certificate shows a different error (see the table at the end). Firefox shows SSL_ERROR_NO_CYPHER_OVERLAP for a cipher or certificate refusal, and SSL_ERROR_UNSUPPORTED_VERSION for a TLS 1.0/1.1-only server.

What the Error Looks Like in Each Browser

Every Chromium browser (Chrome, Edge, Brave, Opera) shows the same code. Look for these:

What Causes ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

If the error shows on one website, the cause is that site's server or CDN. If it shows on many websites, something on your device or network is in the way. The causes:

• The server only speaks TLS 1.0 or 1.1. Chrome, Edge and Firefox began blocking both in 2020 (Firefox 78, Chrome and Edge 84); since Chrome 98 (2022) there's no way past it, and Chromium reports such a server as this error (net_error_list.h).
• The server offers only old ciphers, such as RC4, 3DES or export-grade suites. Chrome's TLS code switches 3DES off entirely, so a server that offers nothing else can't be reached.
• No certificate for the name you typed (on some CDNs). On Cloudflare and CloudFront, a hostname with no certificate gets its handshake refused at the first step. On Cloudflare this is the usual cause: the certificate is still activating, the record isn't proxied, a custom certificate expired with nothing to fall back to, or the name is a multi-level subdomain (Cloudflare). A plain nginx or Apache server sends its default certificate instead, which shows a name-mismatch warning.
• Something in the middle — antivirus HTTPS scanning, a company proxy or a VPN that re-encrypts your traffic with old TLS settings.
• A very old device or browser — Windows XP, Android 4.x and browsers that haven't updated in years lack TLS 1.2 or the ciphers servers now require.

We Tried It: Old TLS Servers vs a Modern Client

To show what triggers this error, we connected a modern TLS client (OpenSSL 3.6) to badssl.com's public test servers on 27 October 2026. The TLS 1.0 and 1.1 servers answered with a version the client no longer accepts; the RC4 and 3DES servers refused with a handshake_failure alert. Chrome reports all four as ERR_SSL_VERSION_OR_CIPHER_MISMATCH:

Open https://tls-v1-0.badssl.com:1010/ in Chrome and you'll see this exact error page. If your own site behaves like the first four rows, the fixes for website owners below apply.

How to Fix ERR_SSL_VERSION_OR_CIPHER_MISMATCH (For Users)

You can't change a website's server, so first check whose problem it is. If one site fails, skip to the website owner fixes: only the owner can solve it. If many sites fail, try these. (Turning off QUIC, an old tip, doesn't help here: QUIC failures show ERR_QUIC_PROTOCOL_ERROR.)

Fix 1: Check Whether It's the Site

Open the same site on another device or on mobile data. If it fails there too, the server is the problem.

For a definite answer, run the site through DNS Robot's SSL Checker: for most servers it lists the TLS versions they accept, and for a site on Cloudflare it shows whether any certificate for that name has been issued. A site that accepts only TLS 1.0 or 1.1 can't be opened in Chrome, Edge or Firefox, and there's nothing to click through: Chrome offers no "proceed anyway" for this error.

Fix 2: Update Your Browser and Operating System

Very old browsers and systems lack TLS 1.2, TLS 1.3 or the ciphers servers now use. Update Chrome at chrome://settings/help and Edge at edge://settings/help, then update the operating system.

Internet Explorer on Windows XP and Vista, and the stock browser on Android 4.0-4.3, lack TLS 1.2 with today's ciphers and fail on most HTTPS sites.

Fix 3: Check Antivirus HTTPS Scanning

Antivirus suites that scan HTTPS (Avast, Kaspersky, Bitdefender, ESET, Norton) sit in the middle of every connection and make their own TLS connection to the website. If their TLS settings are out of date, sites that require modern TLS fail.

Turn off only the HTTPS-scanning part, which suites name differently (Avast's Web Shield HTTPS scanning, ESET's SSL/TLS protocol filtering, Bitdefender's encrypted web scan, Kaspersky's encrypted connection scanning), and reload. If the error goes away, update the antivirus or add the site as an exception rather than leaving scanning off.

Fix 4: Disconnect a VPN or Proxy

Company proxies, and VPNs with a web-protection or HTTPS-inspection feature, make their own TLS connection to the site (an ordinary VPN tunnel doesn't). Disconnect and reload. If the site works, turn that feature off or ask the provider (or your IT team) to update their TLS settings.

How to Fix ERR_SSL_VERSION_OR_CIPHER_MISMATCH (For Website Owners)

If visitors report this error on your site, the server or CDN that answers on port 443 can't agree on TLS with modern browsers. Check it with the SSL Checker, then:

Fix 1: Make Sure Every Name Has a Certificate

On Cloudflare, CloudFront and some other CDNs, a hostname with no certificate gets its handshake refused, and browsers show this error instead of a certificate warning. A plain nginx or Apache server usually sends its default certificate instead (ERR_CERT_COMMON_NAME_INVALID), or, with nginx's ssl_reject_handshake, an unrecognized_name alert (ERR_SSL_UNRECOGNIZED_NAME_ALERT). Check every name visitors use: example.com, www.example.com and each subdomain.

Run each name through the SSL Checker, or test from a terminal (OpenSSL 1.1.1 or later; if you see "Could not find certificate", the server refused the handshake for that name):

# Does the server present a certificate for this exact name?
openssl s_client -connect example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

# Which TLS versions and ciphers does it accept?
nmap --script ssl-enum-ciphers -p 443 example.com

Fix 2: Enable TLS 1.2 and TLS 1.3

Every current browser needs at least TLS 1.2. Enable TLS 1.2 and TLS 1.3 and nothing older:

# nginx (site config or nginx.conf)
ssl_protocols TLSv1.2 TLSv1.3;

# Apache (ssl.conf)
SSLProtocol -all +TLSv1.2 +TLSv1.3

# Then check the config and reload
sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

After reloading, test again with the SSL Checker or Qualys SSL Labs to confirm only TLS 1.2 and 1.3 are offered.

Fix 3: Offer Modern Cipher Suites

With TLS 1.2 on, the server needs a cipher browsers still accept. Offer ECDHE with AES-GCM or ChaCha20-Poly1305 (Mozilla's set); RC4, 3DES, export and NULL ciphers are refused.

# nginx (TLS 1.2 ciphers; TLS 1.3 ciphers are always on)
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;

# Apache
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

Fix 4: Cloudflare-Specific Fixes

Cloudflare's own guide for this error says it happens when the hostname isn't covered by a certificate (Cloudflare). Check, in order:

• Is the certificate active? A new domain gets its Universal SSL certificate within 15 minutes to 24 hours. See SSL/TLS → Edge Certificates: it must say Active.
• Is the DNS record proxied? The certificate is only presented for proxied (orange-cloud) records. A DNS Lookup of a proxied name returns Cloudflare's addresses, not your server's.
• Did a custom certificate expire? Cloudflare removes it after expiry; if no other active certificate (such as Universal SSL) covers the name, visitors get this error instead of a certificate warning.
• Is it a multi-level subdomain? On a full setup, Universal SSL covers example.com and *.example.com only, not test.dev.example.com. Use an Advanced or custom certificate, or Total TLS (which needs Advanced Certificate Manager).

Fix 5: Check Other CDNs and Load Balancers

If a CDN or load balancer (CloudFront, Fastly, Akamai, a cloud load balancer) ends the TLS connection, its settings decide, not your server's:

• A certificate for every hostname, attached to the right distribution or listener
• Minimum TLS 1.2 in its security policy, with modern ciphers
• SNI support if several domains share one IP address

How to Test Your SSL Configuration

After making changes, verify your SSL setup is correct. These tools help you catch problems before your visitors do.

• DNS Robot SSL Checker — Quick check of certificate status, expiration, chain completeness, and issuer. Results in seconds.
• Qualys SSL Labs — Deep scan of TLS versions, cipher suites, protocol support, and known vulnerabilities. Gives a letter grade (aim for A or A+).
• OpenSSL CLI — Test from the command line with openssl s_client -connect domain.com:443 to see the raw handshake, certificate chain, and negotiated cipher.
• Chrome DevTools — on a page that loads, the Security (or Privacy and security) panel shows the TLS version and cipher used.

# Quick check: protocol, cipher and certificate in a few lines
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -brief </dev/null

# Does it accept TLS 1.2? TLS 1.3?
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_2 -brief </dev/null
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 -brief </dev/null

Related SSL/TLS Errors

Chrome has several TLS and certificate errors, each from a different step:

Guides for the neighbours: ERR_SSL_PROTOCOL_ERROR, ERR_CERT_AUTHORITY_INVALID and Your connection is not private.