Views: 21

SSL_ERROR_UNSUPPORTED_VERSION Fix (Firefox)

SSL_ERROR_UNSUPPORTED_VERSION: server offers only TLS 1.0/1.1, Firefox refuses. Fix at the server, not about:config. Free instant check, no sign-up.

Check your domain for this issue now

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

Problem

Firefox shows Secure Connection Failed with the error code SSL_ERROR_UNSUPPORTED_VERSION. The page never loads, and it dies during the TLS handshake — before any certificate warning appears.

Symptoms

  • Firefox reports SSL_ERROR_UNSUPPORTED_VERSION; the same server in Chrome shows ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
  • The failure happens instantly, and you never reach a “Warning: Potential Security Risk Ahead” certificate page.
  • Older browsers, old phones, or an internal legacy client can still reach the site while modern Firefox cannot.
  • It’s usually one specific site or internal appliance, not the whole web.

What This Error Actually Means

TLS starts by agreeing on a protocol version. The client sends the highest version it’s willing to speak; the server picks one both sides support. SSL_ERROR_UNSUPPORTED_VERSION means there was no overlap: the server’s newest offering is TLS 1.0 or 1.1, and Firefox refuses to go that low.

That refusal is deliberate and permanent. Firefox 74 removed TLS 1.0 and 1.1 on March 10, 2020. Mozilla briefly walked it back a few weeks later — a remote preference flip to keep access to government COVID-19 sites that hadn’t upgraded yet — but that reprieve is long over, and the floor is now TLS 1.2. The controlling preference is security.tls.version.min, which defaults to 3 (meaning TLS 1.2). There’s nothing wrong with your Firefox; it’s enforcing a baseline the entire industry agreed on, and RFC 8996 codified in 2021.

The direction matters, because it tells you where not to look. This is a version problem, not a certificate problem and not a cipher problem. It fires before the certificate is ever presented, so certificate expiry or a name mismatch isn’t the cause. And it’s distinct from SSL_ERROR_NO_CYPHER_OVERLAP, where the versions do overlap but no shared cipher exists. If the endpoint simply can’t speak TLS 1.2, no amount of certificate or cipher tweaking will help — the handshake dies one step earlier than any of that.

Top 3 Causes

  1. The server tops out at TLS 1.1 - The web server, or more often an old load balancer, WAF, or hardware appliance terminating TLS in front of it, was configured years ago with a maximum of TLS 1.0/1.1 and never updated. Legacy IIS on Windows Server 2008/2008 R2 and aging network appliances are classic offenders. The origin might support TLS 1.2 while the box in front does not.
  2. A TLS-intercepting middlebox downgrades the connection - Antivirus “HTTPS scanning,” a corporate proxy, or a captive appliance sits between you and the site, re-encrypting traffic with its own outdated TLS stack. Here the symptom appears on many or all sites, not one — a strong tell that the problem is local to your machine or network, not the destination.
  3. Firefox’s minimum was raised past what the site offers - Someone hardened security.tls.version.min to 4 (TLS 1.3 only) in about:config or via enterprise policy, and the site only speaks TLS 1.2. Less common, but it turns a healthy server into a failure that looks like the server’s fault.

Diagnose with DechoNet

  • SSL Check to see exactly which TLS versions the endpoint negotiates. If the highest it offers is 1.0 or 1.1, the fix is unambiguously server-side — enable TLS 1.2/1.3 there. If it already offers TLS 1.2/1.3 but Firefox still fails, the problem is on your side: a raised security.tls.version.min, or a TLS-intercepting proxy or antivirus rewriting the handshake.
  • HTTP Check to confirm whether an HTTP-to-HTTPS redirect is pushing you onto the endpoint that can’t negotiate, versus a separate host that can.

Resolution Checklist

  • Find the real TLS terminator. Run SSL Check and confirm whether it’s the origin or a CDN/load balancer/appliance in front that caps at TLS 1.1 — fix the protocol policy where TLS actually terminates, not just at the origin.
  • Enable TLS 1.2 and 1.3 on that endpoint, and disable SSLv3, TLS 1.0, and TLS 1.1 for good. Mozilla’s “intermediate” server-config profile is a safe baseline.
  • If it fails on every site, suspect a local intercepting proxy or antivirus HTTPS scanning. Temporarily disable HTTPS/SSL scanning in the security product and retest.
  • Check your own security.tls.version.min in about:config. It should be 3 (TLS 1.2). A value of 4 refuses any server that isn’t TLS 1.3.
  • Treat the about:config downgrade as a last resort. Lowering the minimum to reach a legacy site works, but it weakens every connection Firefox makes — undo it once you’re done, and push the site owner to upgrade.
  • Re-run SSL Check after the server change to confirm TLS 1.2/1.3 now negotiates.

When to Escalate

  • If you don’t control the server and it only offers TLS 1.0/1.1, escalate to whoever owns it — the fix is enabling modern TLS on their end, and no client-side setting is a safe permanent answer.
  • If the downgrade traces to a corporate proxy or mandated antivirus, take it to IT: their middlebox is enforcing weaker TLS than the browser, which is the opposite of what security tooling should do.

Related Tools

Related Guides

Share this guide

[Ad] Guide Detail Inline
← Back to All Guides