Browser errors
NET::ERR_SSL_OBSOLETE_VERSION: site uses TLS 1.0 or 1.1
NET::ERR_SSL_OBSOLETE_VERSIONNET::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 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:
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:
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 |
| Safari | Safari can't establish a 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:
ssl_protocols TLSv1.2 TLSv1.3;
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, 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.
FAQ
Is there a Chrome flag to allow TLS 1.0 again?
No. The temporary enterprise policy that allowed it has been removed. For an old device you own, use its local HTTP interface on a trusted network or replace its firmware; do not try to downgrade the browser.
Why are TLS 1.0 and 1.1 considered unsafe?
They depend on SHA-1 and MD5 in the handshake, lack modern AEAD cipher suites, and have a history of attacks such as BEAST and POODLE variants. RFC 8996 lists the reasons in detail.
Our internal app only works on Internet Explorer mode. Is that why?
Possibly. Old servers that only speak TLS 1.0 sometimes still work in IE mode if Windows itself allows the protocol. That is a stopgap; the server should be upgraded to TLS 1.2.
How can I check which TLS versions my server supports?
Run curl ssl.sh/example.com or the SSL checker, which lists every protocol version the server accepts. From a terminal you can also probe each version with openssl s_client -tls1_2 and -tls1_3; a successful handshake prints the negotiated protocol, while a failure ends with an alert such as protocol version.