# NET::ERR_SSL_OBSOLETE_VERSION: site uses TLS 1.0 or 1.1

> NET::ERR_SSL_OBSOLETE_VERSION means the server only offered TLS 1.0 or 1.1. Browsers have removed both; the server must enable TLS 1.2 or 1.3.

Source: https://ssl.sh/errors/net-err-ssl-obsolete-version/
Last updated: 2026-11-10

**NET::ERR_SSL_OBSOLETE_VERSION means the website only speaks TLS 1.0 or TLS 1.1, which browsers have retired.** Chrome used this code while it phased the old versions out; today the same server usually triggers [ERR_SSL_VERSION_OR_CIPHER_MISMATCH](https://ssl.sh/errors/err-ssl-version-or-cipher-mismatch/) instead. Either way, the server needs TLS 1.2 or newer.

## Is it the site or your device?

It is the site. Confirm which protocol versions the server supports with the [SSL checker](https://ssl.sh/tools/ssl-checker/):

```bash
curl ssl.sh/example.com
```

If TLS 1.2 and TLS 1.3 are both missing, the owner must update the server. There is no safe visitor-side fix: re-enabling outdated protocols in your browser, even if possible, weakens every connection you make. Contact the site owner, or for an old device on your own network, update its firmware.

## Causes

### 1. Old server software

Windows Server 2008 (not R2) without updates, old Java application servers, or OpenSSL 0.9.8 cannot offer TLS 1.2. Check directly:

```bash
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null 2>&1 | grep -E "Protocol|alert"
```

### 2. TLS 1.2 explicitly disabled

Hardening guides from a decade ago sometimes produced odd configurations, or a registry change on Windows disabled TLS 1.2 by mistake. Review `ssl_protocols` in Nginx, `SSLProtocol` in Apache, or the SCHANNEL registry keys on Windows.

### 3. Embedded devices and appliances

Printers, UPS cards, KVMs and old NAS units often ship TLS stacks that stopped at TLS 1.0. Firmware updates sometimes add TLS 1.2; otherwise isolate the device and use its management interface from a trusted network.

### 4. A proxy or load balancer in front

The origin supports TLS 1.2, but an old load balancer or reverse proxy terminates TLS with outdated settings. Test the public endpoint, not the origin.

## What it looks like in each browser

| Browser | What you see |
|---|---|
| Chrome / Edge (current) | "This site can't provide a secure connection" with `ERR_SSL_VERSION_OR_CIPHER_MISMATCH` |
| Chrome (2020-2021) | A warning that the connection is not fully secure with `NET::ERR_SSL_OBSOLETE_VERSION` |
| Firefox | "Secure Connection Failed" with [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/) |

## How site owners fix it

Enabling TLS 1.2 and 1.3 on the server, or on the proxy in front of it, fixes it.

**1. Enable modern protocols.** Nginx:

```nginx
ssl_protocols TLSv1.2 TLSv1.3;
```

Apache:

```apache
SSLProtocol -all +TLSv1.2 +TLSv1.3
```

**2. On Windows Server,** enable TLS 1.2 for both client and server under the SCHANNEL `Protocols` registry keys as documented by Microsoft, then reboot. Upgrade unsupported Windows versions.

**3. Generate a tested configuration** with the [TLS config generator](https://ssl.sh/tools/tls-config-generator/), which also picks matching cipher suites.

**4. Verify** with `curl ssl.sh/example.com`: TLS 1.2 and 1.3 should show as supported and TLS 1.0/1.1 as disabled. Background: [TLS 1.3](https://ssl.sh/learn/tls-1-3/).