Problem

Chrome shows ERR_SSL_OBSOLETE_VERSION and the HTTPS page won’t load — no content, and no “proceed anyway” option. It’s not a certificate warning; the connection failed over the protocol version before certificate checks mattered.

The error means one thing: the TLS endpoint the browser reached offers only TLS 1.0 or TLS 1.1, and the browser no longer speaks those. RFC 8996 formally deprecated both in March 2021, and the browsers moved first — Chrome and Edge removed them in version 84, Firefox in 78, and Safari in 14, all through 2020. Since then, a server that can only negotiate TLS 1.0/1.1 is, from a modern browser’s point of view, speaking a language that no longer exists.

Symptoms

  • Chrome/Edge: ERR_SSL_OBSOLETE_VERSION, a full error page with no bypass.
  • Firefox: a “Secure Connection Failed” page citing an unsupported or obsolete protocol.
  • The connection dies during the handshake, before any “your connection is not private” certificate stage.
  • Older devices or an internal browser pinned to an old version may still load the same site — which is the tell that the server, not the client, is stuck on old TLS.

Where the obsolete endpoint actually lives

This is the part people skip, and it’s why “I enabled TLS 1.2 and it still fails” happens. The browser talks to whatever terminates TLS for your site, and that isn’t always the box you think you fixed.

  1. A CDN or load balancer in front of the origin. If Cloudflare, Fastly, an AWS/GCP load balancer, or an nginx reverse proxy terminates TLS, the protocol the browser sees is that layer’s setting — not your origin’s. Raising the minimum TLS version on the origin changes nothing a visitor experiences. Fix it at the edge that actually faces the internet.
  2. The origin web server itself. When there’s no proxy, it’s your Apache/nginx/IIS config serving an ancient ssl_protocols line.
  3. An appliance or admin panel. NAS boxes, printers, routers, old firewalls, and management consoles often ship a TLS stack frozen at the firmware’s release date. These throw ERR_SSL_OBSOLETE_VERSION constantly and the only real fix is a firmware update (or putting a modern reverse proxy in front).

Fix: add modern TLS, don’t resurrect the old one

The goal is to offer TLS 1.2 and 1.3 and stop offering 1.0/1.1 — in that order of importance. Enabling 1.2/1.3 is what clears the error; disabling the old ones is the security cleanup.

  • nginx — in your server or http block: 
    ssl_protocols TLSv1.2 TLSv1.3;
  • Apache (mod_ssl): 
    SSLProtocol -all +TLSv1.2 +TLSv1.3
  • IIS / Windows Server. TLS 1.2 is on by default on currently supported Windows Server versions; the usual problem is an old build or TLS 1.0/1.1 left enabled. These are toggled in the SCHANNEL registry (HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols); editing those keys by hand is error-prone, so most admins use a vetted helper tool rather than typing registry paths. Enable TLS 1.2 (and 1.3 where the OS supports it), then disable 1.0 and 1.1.
  • CDN / managed TLS. Find the “Minimum TLS Version” setting in the dashboard and set it to 1.2. This is the fix the public web needs most often, because the edge is what the browser actually reaches.

After any change, reload the service and test against a fresh hostname — TLS results get cached, so a stale check can show the old protocol for a while.

A note on the tempting shortcut: there’s an enterprise browser policy (SSLVersionMin) that administrators could once set to tolerate old TLS, and some stacks let you force TLS 1.0 back on. Don’t. RFC 8996 deprecated these protocols for cause, and re-enabling them swaps a loud, honest error for a quiet downgrade risk — while newer clients keep refusing you anyway.

Diagnose with DechoNet

  • SSL Check shows exactly which TLS versions the endpoint the world actually reaches offers — so you can confirm whether 1.2/1.3 are present and whether the layer you fixed is the layer visitors hit.
  • HTTP Check follows redirects to the final HTTPS endpoint, which helps when a CDN or load balancer (not the origin) is the one stuck on old TLS.
  • Port Check confirms 443 is reachable at all, separating “wrong TLS version” from “nothing is listening.”

Resolution Checklist

  • Identify what terminates TLS for the hostname — origin, CDN, or load balancer — and change the setting there.
  • Enable TLS 1.2 and TLS 1.3; this is what clears ERR_SSL_OBSOLETE_VERSION.
  • Disable TLS 1.0 and 1.1 (and remove weak ciphers like RC4/3DES while you’re in the config).
  • If a CDN fronts the site, set its Minimum TLS Version to 1.2 — origin changes alone won’t help.
  • For an appliance or admin panel stuck on old TLS, update firmware or front it with a modern reverse proxy.
  • Re-run an SSL check against a fresh hostname to confirm 1.2/1.3 actually negotiate.

When to Escalate

  • If a CDN or managed platform terminates TLS and you can’t find a minimum-version control, escalate to that provider — the fix isn’t yours to make at the origin.
  • If an embedded device genuinely can’t do TLS 1.2 and can’t be updated, treat continued TLS 1.0 as a security decision for the owner, and isolate the device behind a modern proxy rather than re-weakening the public endpoint.
  • If TLS 1.2/1.3 are present everywhere you can see and the error persists only for some users, suspect a middlebox on their network (antivirus TLS inspection, a corporate proxy) terminating with old protocols — see the sibling case, ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.