Is SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT a certificate problem?

No, and reissuing the certificate does nothing. This error fires during protocol-version negotiation, before the certificate is the deciding factor. It means Firefox received a fatal *inappropriate_fallback* alert — TLS alert code 86, defined in RFC 7507 — sent by the server. The server saw the connection arrive as a downgraded *retry*: the handshake carried the special marker TLS_FALLBACK_SCSV (cipher-suite value 0x5600), which means 'I already tried a higher TLS version, it didn't work, so I'm falling back to this lower one.' The server then noticed it actually supports something higher than what was offered, decided the downgrade was inappropriate, and aborted. None of that touches the certificate. A new cert changes nothing because the handshake never got to the point of trusting one.

Why does it happen on every site, or on many unrelated sites at once?

That pattern almost always means something on your own machine or network is intercepting TLS and doing a broken downgrade dance — most often antivirus 'HTTPS scanning' or 'SSL/TLS inspection', or a corporate proxy that terminates and re-originates TLS. Modern Firefox does not do insecure protocol-version fallback on its own anymore (Mozilla removed it around Firefox 37, in 2015), so when you see this across the board, Firefox usually isn't the one downgrading — an inline security product is, and it's adding TLS_FALLBACK_SCSV to a retry that the real servers correctly refuse. The tell is breadth: if it's many unrelated HTTPS sites from one device or one office network, look local first.

It only fails on one specific site. What's different there?

A single-site failure points at that server's edge, not your machine. Somewhere in front of the origin — the server itself, a load balancer, or a middlebox — the first, higher-version handshake fails, so a fallback attempt goes out marked as a fallback, and a correctly configured server on the same path then rejects it with inappropriate_fallback. That is often a *version-intolerant* device: old software that mishandles a modern ClientHello (a large one, or TLS 1.3) and kills the connection, provoking the downgrade. RFC 7507 is explicit that the alert doesn't prove an attack — a network glitch that breaks the first attempt can trigger the same fallback. An external TLS check tells you whether the origin negotiates cleanly for everyone else, which isolates the problem to your path versus theirs.

Views: 6

SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT: Firefox Fix

SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT is a rejected TLS downgrade, not a cert error. Check antivirus HTTPS scanning, proxies. 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 refuses to load the page with SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT and Secure Connection Failed. The instinct is to blame the certificate, and it’s wrong: nothing about the certificate is in question here. The connection failed one step earlier, over which version of TLS to speak — and the server ended it because it looked like a downgrade the server was unwilling to accept.

Symptoms

Firefox shows Secure Connection Failed with the code SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT.
There is no “Add Exception” / “Accept the Risk” button — this isn’t an untrusted-certificate warning, so Firefox offers no override.
It hits either one specific site or many unrelated HTTPS sites at once — and which of those it is points straight at the cause.
The broad version often started after installing or updating antivirus with web/HTTPS protection, or on a managed corporate network.
The same URL may work in another browser or on another machine, which makes it look like a Firefox bug.

What This Error Actually Means

A TLS connection starts with the client proposing the highest protocol version it supports. Years ago, when a server or a buggy middlebox choked on that, clients would quietly retry at a lower version — an insecure fallback. Attackers learned to force those retries on purpose, knocking a connection down to a weak protocol they could break; POODLE, in 2014, was the famous example against SSL 3.0.

The fix was to make fallback visible. RFC 7507 defined a signal, TLS_FALLBACK_SCSV (a pseudo-cipher-suite value, 0x5600), that a client includes in its ClientHello to say: this is not my best offer — it’s a fallback retry after a higher version failed. A server that receives that signal, and that itself supports a version higher than the one being offered, must conclude the downgrade is inappropriate and abort with a fatal inappropriate_fallback alert (TLS alert code 86). Firefox surfaces that received alert as SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT.

Read that carefully, because it inverts the usual instinct. The server is not too old to talk to you — it’s rejecting you because it can do better than the version your side asked for. Something upstream of the server decided the first, higher-version handshake had failed and dropped to a lower one, and the server refused to play along. RFC 7507 is careful to note this isn’t proof of an attack: a plain network glitch that breaks the first attempt produces the same fallback and the same rejection. So the real question is never “what’s wrong with the certificate” — it’s who downgraded the connection, and why did the first attempt fail?

Top 3 Causes

Local TLS-inspecting antivirus or a corporate proxy (the many-sites case) — Security software that decrypts HTTPS to scan it — “SSL/TLS inspection”, “HTTPS scanning”, “web shield” — sits between Firefox and the internet as a man-in-the-middle by design. When its own TLS logic does a downgrade dance and stamps the retry with TLS_FALLBACK_SCSV, the real servers on the other side correctly refuse. Because the middlebox handles all your traffic, the failure hits site after site. This is the dominant cause today, precisely because modern Firefox no longer downgrades on its own.
A version-intolerant server or middlebox in front of one origin (the one-site case) — Old software that can’t handle a modern ClientHello — an oversized one, or TLS 1.3 — kills the first handshake. Whatever is on the path then retries at a lower version with the SCSV marker, and a correctly configured server on the same route rejects the downgrade. The origin’s TLS may be fine; a legacy load balancer, WAF, or appliance ahead of it is breaking the modern attempt.
A legacy client, SDK, or old browser that still performs insecure fallback — Some older HTTP libraries and pre-2015 browsers still downgrade-retry and send TLS_FALLBACK_SCSV. Point one of those at a properly hardened modern server and the server does exactly what RFC 7507 tells it to: refuses the downgrade. Here the fix is to update the client, not to weaken the server.

Diagnose with DechoNet

SSL Check runs a full TLS handshake against the host from outside your network and reports the protocol version and cipher it negotiates. If the check completes cleanly at TLS 1.2/1.3, the server negotiates fine for a normal client — so the downgrade is happening on your side of the wire, and the culprit is local TLS-inspecting software or a proxy. If the check also fails or can only reach an old protocol, the problem is at the origin’s edge: a version-intolerant device is breaking the modern handshake and provoking the fallback.
HTTP Check fetches the site from outside your network entirely. A clean external result while your Firefox fails is strong evidence the break is in your local path — your inspection software or network — not the destination.

Resolution Checklist

Split the two cases first. Many unrelated HTTPS sites failing → look local. One site failing → look at that origin’s edge. The breadth of the failure is the single most useful clue.
For the many-sites case, suspect TLS-inspecting antivirus or a proxy. Temporarily disable HTTPS/SSL scanning (ESET, Avast, Kaspersky, Bitdefender and similar all have this feature) and retest. If that clears it, update or reconfigure the product rather than leaving inspection off — an inspector that can’t negotiate cleanly is the bug.
Do not lower security.tls.version.min in Firefox’s about:config. This error is a refused downgrade; forcing your minimum version lower is moving in exactly the wrong direction and weakens every other connection you make.
For the one-site case, run an external SSL check. If it shows the origin only reaching an old protocol or failing to handshake, hand it to whoever owns that server or its load balancer as a version-intolerance problem — the modern handshake needs to succeed so no fallback is attempted.
If the failure comes from a script or app rather than a browser, update the HTTP client or TLS library; old ones that still do insecure fallback are the cause, and the server is behaving correctly.
Re-test after each change and re-run the SSL check to confirm the server negotiates a modern version end to end.

When to Escalate

If disabling local TLS inspection fixes it, escalate to whoever manages that endpoint-security software or the network proxy — they need to update or reconfigure it so its TLS negotiation stops triggering fallback, and leaving inspection permanently off is not an acceptable long-term fix.
If the external SSL check shows the origin’s edge breaking the modern handshake, give it to whoever owns that server, load balancer, or WAF, with the check result as evidence; the fix is to make the current-version handshake succeed, usually by updating the version-intolerant device.
If the error comes from an internal application, route it to the team that owns that client’s HTTP/TLS stack — the durable fix is removing insecure version fallback from the client, not relaxing the servers it talks to.