# ERR_SSL_VERSION_OR_CIPHER_MISMATCH: what it means and how to fix it

> ERR_SSL_VERSION_OR_CIPHER_MISMATCH means the browser and the server share no TLS version or no cipher, so the handshake stops before any page loads. Here is the visitor fix, then how to tell the two server causes apart and fix each.

Updated 2026-11-10 · Security · HTML version: https://getreport.app/guides/err-ssl-version-or-cipher-mismatch

ERR_SSL_VERSION_OR_CIPHER_MISMATCH is Chrome's error when the browser and the server cannot find a TLS version or a cipher they both support, so the secure handshake stops before any page loads. The page says the site "uses an unsupported protocol", and under the details: "The client and server don't support a common SSL protocol version or cipher suite." Nearly always the server is the cause: it still offers only TLS 1.0 or 1.1, or a cipher list current browsers have dropped. Visitors get a two-minute check first; site owners get the probes that tell the version case from the cipher case. This guide is one stop in our tour of [SSL errors, browser by browser](https://getreport.app/guides/ssl-errors-by-browser), which covers how Firefox and Safari word the same failures.

![Headless Chromium 153's hello offers TLS 1.3 and 1.2 with modern ciphers. The healthy lab server shares both and completes the handshake; the TLS 1.0 only server shares no version and the Camellia only server shares no cipher. Notice that both broken servers give the same browser error while curl prints a different message for each](https://getreport.app/guides/img/err-ssl-version-or-cipher-mismatch/diagram.svg "Two different server faults, one browser error. The OpenSSL message is what tells them apart.")

## Quick answer

- **Visitor**: try another device over mobile data. If it fails everywhere, only the site's owner can fix it. If only your device fails, update it and turn off HTTPS scanning in antivirus, VPN or proxy software.
- **Site owner**: your server, CDN or load balancer offers no version or cipher current browsers accept. Run `curl -sS -o /dev/null https://example.com/`: `alert protocol version` points at the version, `alert handshake failure` at the cipher list.
- **Fix the version case** by allowing TLS 1.2 and 1.3 (`ssl_protocols TLSv1.2 TLSv1.3;` in nginx, `SSLProtocol -all +TLSv1.2 +TLSv1.3` in Apache, Minimum TLS Version 1.2 at a CDN).
- **Fix the cipher case** with a maintained list such as Mozilla's "intermediate" profile, with suites for your certificate's key type.
- **Behind a CDN**, check that the exact host name has an active edge certificate.
- Confirm with the [SSL checker](https://getreport.app/tools/ssl-check): the HTTPS and minimum TLS version findings should pass.

## What the error means

Every HTTPS connection starts with a handshake: the browser's first message, the ClientHello, lists the TLS versions and cipher suites it accepts, and the server must pick one of each. If it supports nothing on those lists, it sends an alert and the connection ends. Chrome, Edge and other Chromium browsers report that as ERR_SSL_VERSION_OR_CIPHER_MISMATCH. The [SSL handshake guide](https://getreport.app/guides/ssl-handshake) walks through the full exchange.

The name covers two faults, and the browser does not say which one you have:

- **No common version.** Current browsers offer TLS 1.2 and 1.3 only. Chrome, Edge, Firefox and Safari all announced the removal of TLS 1.0 and 1.1 for 2020, and RFC 8996 formally deprecated both in 2021. A server that stops at 1.1 shares no version with them.
- **No common cipher.** The version matches, but every cipher the server allows is one the browser no longer offers, or one that cannot work with the server's certificate.

This happens before the certificate is checked, which is why it differs from "Your connection is not private". In our lab, Chromium showed this error on both broken servers even though it did not trust their certificate; where the handshake worked, the same certificate gave `ERR_CERT_AUTHORITY_INVALID` instead.

## Same error, two causes: what we reproduced

On 30 October 2026 we built both faults on local lab servers, each serving our example-shop.hr fixture page with `openssl s_server`, and pointed headless Chromium 153 and curl at them:

| Lab server | Server setting | Chromium 153 | curl 8.5.0 (OpenSSL 3.0.13) |
| --- | --- | --- | --- |
| Port 8443, healthy | TLS 1.2 and 1.3, default ciphers | Handshake completes (then `ERR_CERT_AUTHORITY_INVALID`, lab authority untrusted) | `200` |
| Port 8444, version case | TLS 1.0 only | `net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH` | `tlsv1 alert protocol version` |
| Port 8445, cipher case | TLS 1.2, only `CAMELLIA128-SHA` | `net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH` | `sslv3 alert handshake failure` |
| Port 8452, TLS 1.3 only | TLS 1.3 only | Page loads (with certificate errors ignored, lab only) | not run |

One browser error, two faults, two fixes. Tools built on OpenSSL keep them apart, which is why the diagnosis below starts in a terminal.

The server flags were `-tls1 -cipher 'DEFAULT@SECLEVEL=0'` for port 8444 and `-no_tls1_3 -cipher 'CAMELLIA128-SHA:@SECLEVEL=0'` for port 8445. Camellia is a sound cipher, but Chromium does not offer it, so a server allowing nothing else locks Chromium out. Suites browsers dropped long ago, such as RC4 (banned in TLS by RFC 7465) or 3DES, fail the same way.

## If you're a visitor: the quick fix

1. **Try another device and network.** Use your phone over mobile data. If it fails there too, tell the site's owner.
2. **Update your browser and your operating system.** Very old browsers and systems may not offer what a modern server requires. If your device no longer gets updates, use another device.
3. **Turn off HTTPS scanning in antivirus software, and pause VPNs and proxy extensions.** Products that inspect encrypted traffic make their own connection to the site; if theirs is outdated, the site refuses it.
4. **On a work or school network, try from home.** A company proxy that inspects TLS can cause the same failure.

Don't look for a way to turn TLS 1.0 back on: current Chrome has no ordinary setting for it, and weakening your browser for one outdated site exposes every other site you visit.

## If you own the site: find which one it is

Test from outside your network, so a local proxy or VPN cannot hide the result. Start with the SSL checker:

> **Free tool:** [SSL checker: free SSL certificate and TLS test](https://getreport.app/tools/ssl-check): Free SSL checker: test certificate expiry and chain, TLS versions, HTTPS redirects, HSTS and mixed content on any site, with the fix for each. No sign-up.

The checker runs a modern handshake (TLS 1.2 and newer), then one offering only TLS 1.0 and 1.1. With this error the modern handshake fails, so the report cannot load the page over `https://` at all. Once fixed, both findings below pass; the second reads "TLS 1.0/1.1 handshakes are refused" with the negotiated version:

> **Check: The site is served over HTTPS.** Browsers label HTTP pages "Not secure" and Google uses HTTPS as a small ranking signal. Anyone on the network can read or alter what visitors see.
>
> 1. Get a certificate (Let's Encrypt is free) and enable HTTPS on your host.
> 2. Redirect every http:// URL to https:// with a 301.

> **Check: The server only accepts TLS 1.2 or newer.** TLS 1.0 and 1.1 have known weaknesses and every major browser dropped them in 2020. A server that still accepts them lets an attacker downgrade a connection to one they can break.
>
> 1. Set the minimum protocol to TLS 1.2 (nginx: ssl_protocols TLSv1.2 TLSv1.3; Apache: SSLProtocol -all +TLSv1.2 +TLSv1.3).
> 2. Behind Cloudflare or another CDN, set "Minimum TLS Version" to 1.2 in its dashboard.

### Step 1: read curl's alert

curl prints the server's alert in plain words. The command we ran in the lab (Linux, local servers):

```bash
curl --noproxy '*' -sS -o /dev/null -w "%{http_code}\n" --resolve example-shop.hr:8444:127.0.0.1 --cacert ca.pem https://example-shop.hr:8444/index.html
```

On your computer (macOS, Linux, or Windows with Git Bash or WSL), for your site:

```bash
curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/
```

The two lab outputs, exactly as recorded:

```text
8444 example-shop.hr       curl: (35) OpenSSL/3.0.13: error:0A00042E:SSL routines::tlsv1 alert protocol version
8445 example-shop.hr       curl: (35) OpenSSL/3.0.13: error:0A000410:SSL routines::sslv3 alert handshake failure
```

- **`alert protocol version`** is TLS alert 70, protocol_version: the server rejected every version curl offered. That is the version case.
- **`alert handshake failure`** is alert 40, handshake_failure: the versions matched, but the server found nothing else it could agree to. Most often that is the cipher list, so check it next.

These are curl's messages with OpenSSL 3; builds on another TLS library, such as Apple's curl on macOS, word them differently. Then use the probes in step 2.

### Step 2: probe each TLS version

`openssl s_client` asks for one version at a time. Run these on your computer with your host name in both places:

```bash
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null
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_1 -cipher 'DEFAULT@SECLEVEL=0' </dev/null
openssl s_client -connect example.com:443 -servername example.com -tls1 -cipher 'DEFAULT@SECLEVEL=0' </dev/null
```

Without `-cipher 'DEFAULT@SECLEVEL=0'`, OpenSSL 3 refuses TLS 1.0 and 1.1 itself ("no protocols available"), which says nothing about the server. Our lab results:

| Lab server | `-tls1` | `-tls1_1` | `-tls1_2` | `-tls1_3` |
| --- | --- | --- | --- | --- |
| 8443, healthy | `tlsv1 alert protocol version` (alert 70) | `tlsv1 alert protocol version` (alert 70) | handshake completes | handshake completes |
| 8444, TLS 1.0 only | handshake completes | `unsupported protocol` | `unsupported protocol` | `tlsv1 alert protocol version` (alert 70) |
| 8452, TLS 1.3 only | not run | not run | `tlsv1 alert protocol version` (alert 70) | handshake completes |

A healthy server completes 1.2 and 1.3 and refuses 1.0 and 1.1. If only `-tls1` or `-tls1_1` completes, you have the version case. `unsupported protocol` is your own OpenSSL rejecting a server that answered with TLS 1.0.

### Step 3: if the versions are fine, test the cipher

If `-tls1_2` or `-tls1_3` completes but browsers still fail, either browsers reach a different machine (a CDN, see cause 3), or the probe agreed on a cipher no browser offers. Ask for the cipher you suspect. On the Camellia server, this lab probe connected:

```bash
openssl s_client -connect 127.0.0.1:8445 -servername example-shop.hr -cipher 'CAMELLIA128-SHA:@SECLEVEL=0'
```

It reported `Protocol TLSv1.2, Cipher CAMELLIA128-SHA`: only a client offering Camellia gets in. On your own server, it is quicker to read the cipher line in its configuration and compare it with the lists below.

## Causes, most likely first

| Cause | What you see | Fix |
| --- | --- | --- |
| Only TLS 1.0 or 1.1 at the server, CDN or load balancer | `alert protocol version`; only old-version probes complete | Allow TLS 1.2 and 1.3 where TLS ends |
| Cipher list with no suite browsers offer | `alert handshake failure`; versions look fine | Replace the list with a maintained profile |
| No edge certificate for this host name on the CDN | Error on one host name only, often new or a deeper subdomain | Add the name and wait for, or order, its edge certificate |
| Old device or browser on the visitor's side | Fails on one device only | Update the browser and system, or use another device |
| Antivirus, VPN or company proxy inspecting TLS | Fails on one device or one network only | Turn off HTTPS scanning, or ask the network's admin |

### 1. Only TLS 1.0 or 1.1 on the server

The most common cause. It shows up on servers set up years ago and never changed, old control panels, appliances such as routers and printers, and load balancers on an old security policy. Our guide to [turning TLS 1.0 and 1.1 off](https://getreport.app/guides/tls-1-0-and-1-1-turning-legacy-protocols-off) covers logging versions before a switch; here modern browsers are already locked out, so there is nothing to wait for.

### 2. A cipher list no browser can use

The server allows TLS 1.2, but only with suites browsers no longer offer (RC4, 3DES, Camellia on its own) or suites that need a different certificate. In TLS 1.2 the suite name includes the certificate type: `ECDHE-ECDSA` suites need an ECDSA certificate and `ECDHE-RSA` suites an RSA one. A list with only ECDSA suites on a server with an RSA certificate leaves nothing to agree on.

### 3. No edge certificate for the host name

Behind a CDN or cloud load balancer, the handshake happens at the edge. If the edge has no certificate for the exact name requested, some providers cannot complete the handshake, so browsers show this error while your origin tests clean. This varies by provider. Cloudflare's troubleshooting docs list it for proxied host names whose edge certificate is not active yet, and its free Universal SSL certificate covers the apex and first-level subdomains (`www.example.com`), not deeper ones such as `shop.eu.example.com`.

### 4. An old client

If your server allows TLS 1.2 and 1.3 with a maintained cipher list, a client that still fails is too old for most of the web, and the fix is on its side. If you set TLS 1.3 only, clients that stop at 1.2 get this error from you: our TLS 1.3-only server refused the `-tls1_2` probe with alert 70.

### 5. Software inspecting HTTPS

Antivirus suites, VPN clients and company proxies that scan HTTPS connect to your server on the visitor's behalf. When that software is outdated, your server is right to refuse it; a help page can tell affected visitors to update it or switch the scanning off.

## Fixes by platform

The snippets in this section are from the nginx, Apache and Mozilla documentation, not run in our lab. Mozilla's [SSL Configuration Generator](https://ssl-config.mozilla.org/) produces the same "intermediate" profile for your exact server version; prefer its output if it differs.

### nginx

In the `http` block of `/etc/nginx/nginx.conf`, so every `server` block inherits it:

```nginx
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:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
```

A line in a `server` block overrides it for that site, so search for others with `grep -rn "ssl_protocols\|ssl_ciphers" /etc/nginx/`. Then `sudo nginx -t && sudo systemctl reload nginx`.

### Apache

In the SSL virtual host, or in `ssl.conf` for every site (not in `.htaccess`, because the version and cipher are agreed before Apache reads it):

```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 off
```

`+TLSv1.3` needs Apache 2.4.36 or later with OpenSSL 1.1.1 or later; on older versions use `SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1`. Test with `sudo apachectl configtest`, then reload.

### Cloudflare and other CDNs

Visitors negotiate with the edge, so its settings are the ones that matter. In Cloudflare, open SSL/TLS, then Edge Certificates: set Minimum TLS Version to 1.2 and check that the exact host name has an active certificate. A deeper subdomain needs a certificate that covers it, such as an advanced certificate. Other CDNs and load balancers have the same two settings under their own names: a TLS or security policy, and a certificate per host name.

### Managed and WordPress hosts

On shared and managed hosting, including most WordPress hosts, TLS ends at the host's server or CDN; no WordPress plugin can change it. Send support the `curl` alert from step 1 and the probe results from step 2.

### Windows Server and IIS

IIS uses the TLS settings of Windows itself (Schannel), set for the whole server in the registry or by group policy. Defaults vary by Windows Server version, so check Microsoft's documentation for yours, enable TLS 1.2 (and 1.3 where supported), and restart.

## How to verify the fix

1. The step 1 `curl` command prints a status code such as `200` or `301` instead of an alert.
2. The `-tls1_2` and `-tls1_3` probes complete, and the `-tls1` and `-tls1_1` probes fail with `alert protocol version`.
3. Repeat for every host name visitors use: the apex, `www` and each subdomain.
4. Run the [SSL checker](https://getreport.app/tools/ssl-check) again: HTTPS passes and the minimum TLS version finding reads "The server only accepts TLS 1.2 or newer".
5. Open the site in a private window and on a phone over mobile data.

A certificate warning next means the handshake works and the certificate is the next layer: see [fixing "Your connection is not private"](https://getreport.app/guides/your-connection-is-not-private). ERR_SSL_PROTOCOL_ERROR means the port answers with something that is not TLS ([the ERR_SSL_PROTOCOL_ERROR guide](https://getreport.app/guides/err-ssl-protocol-error)). Behind Cloudflare, a 525 page means the edge works but its link to your server does not ([Cloudflare errors 525 and 526](https://getreport.app/guides/cloudflare-ssl-errors-525-526)).

## How we tested

The getReport team ran every lab command in this guide on 30 October 2026 on Linux, with OpenSSL 3.0.13, curl 8.5.0, Python 3.11 and headless Chromium 153.0.8010.12 driven by Playwright. Each lab server was `openssl s_server -WWW` serving the example-shop.hr fixture homepage on a local port (8443, 8444, 8445 and 8452 as in the tables), with a certificate from a lab authority that curl trusted (`--cacert`) and Chromium did not. We read Chrome's page wording from Chromium 153's own English strings.

What we did not test: Firefox, Safari, Edge as a separate browser, real nginx, Apache or IIS servers, Cloudflare or any other CDN, antivirus HTTPS scanning, VPNs and mobile devices. The nginx, Apache and CDN steps come from their documentation, not from our lab. We did not test RC4 or 3DES servers, or an ECDSA cipher list on an RSA certificate.

## Questions people ask

### What does "uses an unsupported protocol" mean in Chrome?

It means Chrome and the website could not agree on how to encrypt the connection, so Chrome refused to load the page. The line comes with ERR_SSL_VERSION_OR_CIPHER_MISMATCH: the site offers only TLS versions or ciphers that Chrome no longer accepts, usually TLS 1.0 or 1.1. Nothing is wrong with your connection to the internet. Try another device to confirm, and if it fails there too, only the site's owner can fix it.

### Is ERR_SSL_VERSION_OR_CIPHER_MISMATCH my problem or the website's?

Almost always the website's. The error means the server offers no TLS version or cipher that your browser supports, which is a server setting. It is yours only if the site works on other devices and networks but not on yours: then an outdated browser or system, or antivirus or VPN software inspecting HTTPS, is the likely cause. Updating, or turning off HTTPS scanning, fixes those.

### Can I turn TLS 1.0 back on in Chrome to open an old site?

No, not with any ordinary setting in current Chrome, and you should not try to work around it. TLS 1.0 and 1.1 were deprecated because of known weaknesses, and every major browser dropped them in 2020. If you need the site, contact its owner; for a device on your own network, such as an old router or printer, check for a firmware update that adds TLS 1.2.

### Can an expired or self-signed certificate cause ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

No. The version and cipher are agreed before the browser checks the certificate, so certificate problems produce their own errors, such as `NET::ERR_CERT_DATE_INVALID` or `ERR_CERT_AUTHORITY_INVALID`. In our lab, Chromium showed the mismatch error on servers whose certificate it did not trust, and the authority error only on servers where the handshake worked. Fix the mismatch first; a certificate warning may appear next.

### Why does ERR_SSL_VERSION_OR_CIPHER_MISMATCH appear after adding a domain to a CDN?

Because the visitor's handshake now happens at the CDN's edge, and the edge may not have a certificate for that host name yet. Until it does, some CDNs cannot complete the handshake and browsers show ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Check the CDN's certificate list for the exact name. Wait if it is still being issued; if the name is a deeper subdomain the default certificate does not cover, add a certificate for it.

### Can a TLS 1.3-only server cause ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

Yes, for clients that stop at TLS 1.2, such as older devices, some bots and some corporate proxies. Current browsers support TLS 1.3, and in our lab headless Chromium 153 loaded a TLS 1.3-only server, but an OpenSSL probe asking for TLS 1.2 was refused with alert 70. Unless your logs show no TLS 1.2 traffic, allow both TLS 1.2 and 1.3.

## Sources

- [RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446) (accessed October 2026)
- [RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 (alerts, cipher suites)](https://www.rfc-editor.org/rfc/rfc5246) (accessed October 2026)
- [RFC 8996: Deprecating TLS 1.0 and TLS 1.1](https://www.rfc-editor.org/rfc/rfc8996) (accessed October 2026)
- [RFC 7465: Prohibiting RC4 Cipher Suites](https://www.rfc-editor.org/rfc/rfc7465) (accessed October 2026)
- [Chromium: net error list (SSL_VERSION_OR_CIPHER_MISMATCH)](https://source.chromium.org/chromium/chromium/src/+/main:net/base/net_error_list.h) (accessed October 2026)
- [WebKit: Deprecation of legacy TLS 1.0 and 1.1 versions](https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-and-1-1-versions/) (accessed October 2026)
- [Mozilla: Server Side TLS and the SSL Configuration Generator](https://wiki.mozilla.org/Security/Server_Side_TLS) (accessed October 2026)
- [Cloudflare: SSL/TLS troubleshooting](https://developers.cloudflare.com/ssl/troubleshooting/) (accessed October 2026)