# ERR_SSL_VERSION_OR_CIPHER_MISMATCH: causes and server fixes

> ERR_SSL_VERSION_OR_CIPHER_MISMATCH means browser and server share no TLS version or cipher. Usually TLS 1.0-only servers or a CDN with no cert.

Source: https://ssl.sh/errors/err-ssl-version-or-cipher-mismatch/
Last updated: 2026-11-10

**ERR_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](https://ssl.sh/tools/ssl-checker/):

```bash
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:

```bash
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](https://ssl.sh/errors/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](https://ssl.sh/tools/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](https://ssl.sh/errors/ssl-error-no-cypher-overlap/) or [SSL_ERROR_UNSUPPORTED_VERSION](https://ssl.sh/errors/ssl-error-unsupported-version/) |
| Safari | [Safari can't establish a secure connection](https://ssl.sh/errors/safari-cant-establish-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:

```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](https://ssl.sh/tools/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.