Is SSL_ERROR_HANDSHAKE_FAILURE_ALERT a certificate problem?

No — and the fix people reach for first, reissuing the certificate, usually does nothing. This error fires before the certificate ever matters. Firefox's own wording is 'SSL peer was unable to negotiate an acceptable set of security parameters,' and the operative word is *peer*: Firefox received a fatal handshake_failure alert (TLS alert code 40, RFC 5246 §7.2.2) sent by the server. The server looked at what Firefox offered — protocol versions, cipher suites, signature algorithms — and decided none of it was acceptable, so it aborted the handshake before choosing a certificate to present. Certificate errors like SEC_ERROR_UNKNOWN_ISSUER or SSL_ERROR_BAD_CERT_DOMAIN happen *after* the cert is sent. This one happens before. A new cert changes nothing if the server never got far enough to send the old one.

What's the difference between this and SSL_ERROR_NO_CYPHER_OVERLAP?

They describe the same kind of dead end — no mutually acceptable parameters — but from opposite sides of the wire, and that tells you where to look. SSL_ERROR_NO_CYPHER_OVERLAP is Firefox's *own* verdict: Firefox compared what it supports against the server's response and found no shared cipher, so Firefox itself gave up. SSL_ERROR_HANDSHAKE_FAILURE_ALERT is the *server's* verdict delivered to Firefox as an alert: the server evaluated Firefox's ClientHello and refused. The distinction matters because in the alert case the ball was entirely in the server's court — it saw the offer and chose no. That points you at the server's TLS policy (or a demand for a client certificate) rather than at Firefox's cipher list.

It only fails on one specific site or portal. Why?

The single most common reason for a one-site handshake_failure is that the server is asking for a client certificate — mutual TLS — and Firefox didn't have one to send. RFC 5246 §7.4.6 spells this out: if the client sends no certificate, the server MAY respond with a fatal handshake_failure. Corporate portals, government sites, banking back-ends, and internal APIs often require a client cert or smartcard; hit them without the certificate installed in Firefox and you get this exact error, while every ordinary website loads fine. The other one-site cause is a server whose TLS is locked to versions or ciphers your Firefox no longer offers — a legacy appliance stuck on TLS 1.0/1.1, for instance. An external TLS check tells the two apart.

Views: 7

SSL_ERROR_HANDSHAKE_FAILURE_ALERT in Firefox: Fix

SSL_ERROR_HANDSHAKE_FAILURE_ALERT: the server refused the handshake, not the cert. Check TLS version, ciphers, client certs. 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_HANDSHAKE_FAILURE_ALERT and the message Secure Connection Failed — SSL peer was unable to negotiate an acceptable set of security parameters. The instinct is to blame the certificate. That’s the wrong tree. No certificate was rejected here — the connection never got as far as evaluating one. The server ended the handshake on purpose and told Firefox why, and Firefox is relaying that verdict.

Symptoms

Firefox shows Secure Connection Failed with the error code SSL_ERROR_HANDSHAKE_FAILURE_ALERT and the text unable to negotiate an acceptable set of security parameters.
There is no “Add Exception” / “Accept the Risk” button — this isn’t an untrusted-certificate warning, so Firefox offers no override.
It usually hits one specific site, portal, or API and not the wider web.
The same URL may open in Chrome or Edge (different defaults, or a client certificate already installed), which makes it look like a Firefox bug.
On a corporate or government site, it started right after a smartcard was removed, a client certificate expired, or a profile was reset.

What This Error Actually Means

A TLS handshake opens with the client’s ClientHello: a list of everything it’s willing to do — protocol versions, cipher suites, signature algorithms, supported groups (curves). The server’s job is to pick one acceptable combination from that menu. If it can’t find a single acceptable combination — or if it needs something the client didn’t provide — it sends a fatal handshake_failure alert, TLS alert code 40, defined in RFC 5246 §7.2.2: “handshake_failure — Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available.” Firefox surfaces that received alert as SSL_ERROR_HANDSHAKE_FAILURE_ALERT.

Read the word “peer” in Firefox’s message literally. The peer — the server — is the one that couldn’t negotiate. This is not Firefox declining; it’s Firefox being declined. That flips the whole diagnosis. You’re not debugging Firefox’s cipher list (that failure looks like SSL_ERROR_NO_CYPHER_OVERLAP, decided locally). You’re debugging what the server demanded that your Firefox connection didn’t supply.

There are only two shapes that demand can take. Either the server needed more than Firefox offered — a client certificate it didn’t send — or it found nothing acceptable in what Firefox offered: no shared protocol version, no shared cipher, no usable signature algorithm for the certificate it wanted to present. Everything below is a way of telling those two apart.

Top 3 Causes

The server wants a client certificate and Firefox sent none (mutual TLS) — The most common one-site case by far. The server is configured to require client authentication; when Firefox connects without a matching client certificate in its store, the server aborts with handshake_failure exactly as RFC 5246 §7.4.6 permits. Corporate intranets, government services, banking and partner APIs, and admin panels do this. The tell: it’s one endpoint, ordinary sites are fine, and it broke when a smartcard, certificate, or Firefox profile changed. Firefox even tracks this as a known-confusing case in Bugzilla 1362079, because the raw error hides the real cause.
No overlap the server will accept — version, cipher, or signature algorithm — The server evaluated the ClientHello and found nothing usable. A legacy appliance or load balancer stuck on TLS 1.0/1.1 that modern Firefox no longer offers; a server hardened to a cipher list that excludes everything current Firefox proposes; or a signature-algorithm / curve mismatch for the certificate the server holds (an ECDSA-only server meeting a client offer it can’t satisfy). The handshake dies at parameter selection, before any certificate is presented.
SNI or middlebox rejects the ClientHello — The server receives a Server Name Indication it has no virtual host or certificate for and is configured to abort rather than serve a default, or an inline device — a TLS-inspecting proxy, WAF, or load balancer — refuses the connection based on the offered extensions or fingerprint. Here the origin’s own TLS may be perfectly healthy; something in front of it is sending the alert.

Diagnose with DechoNet

SSL Check runs a full TLS handshake against the host from outside your network and reports the protocol versions and cipher suites it actually negotiates. If the check completes and shows a valid handshake, the server can absolutely negotiate with a standard client — so your failure is about what your Firefox connection is (or isn’t) offering: a missing client certificate, a locked-down profile, or a local inspection proxy. If the check also fails to handshake, the server’s TLS policy is the problem — no modern overlap, or it demands a client certificate from everyone — and the fix is server-side.
HTTP Check fetches the site from outside your network entirely. A clean external result while your Firefox fails points at your local path or your specific client setup, not the origin.

Resolution Checklist

Split server vs. client first with an external SSL check. Server negotiates cleanly for the check but fails only in your Firefox → the issue is your client (read on). Server fails the external check too → it’s the server’s TLS config.
If it’s one corporate/government/API endpoint, suspect a client-certificate requirement. Confirm the right client certificate is imported into Firefox (Settings → Privacy & Security → Certificates → View Certificates → Your Certificates) and, for a smartcard, that the PKCS#11 module is loaded and the card is present.
If the external SSL check shows the server only offers old protocols or a narrow cipher set, the fix is server-side: enable TLS 1.2/1.3 and a modern cipher suite on the origin or its load balancer. Don’t lower security.tls.version.min in Firefox’s about:config — that’s a downgrade to match a broken server, not a fix, and it weakens every other connection.
If it fails across many unrelated HTTPS sites, suspect local TLS-inspecting antivirus or a corporate proxy re-negotiating badly. Test with it temporarily disabled; if that clears it, reconfigure or update the inspection software rather than leaving it off.
Re-test after each change and re-run the SSL check to confirm the server side stays clean end to end.

When to Escalate

If the external SSL check shows a healthy server and the endpoint requires a client certificate you don’t have, escalate to whoever administers that service — they issue and enroll the client certificate or smartcard, and only they can confirm which one the endpoint expects.
If the external check confirms the server only speaks obsolete TLS or an incompatible cipher set, hand it to whoever owns that origin or its load balancer as a TLS-configuration problem, with the check result as evidence. This is common on legacy appliances that were never updated.
If the failure hits many sites from one machine or one office network, give it to whoever manages the endpoint security software or the network’s inspection middlebox — an inspecting proxy that can’t negotiate cleanly is the near-certain culprit, and the SSL check proves the real servers are fine.