How to Fix the SSL_ERROR_NO_CYPHER_OVERLAP Error

SSL_ERROR_NO_CYPHER_OVERLAP is the message Firefox shows when it cannot complete a TLS handshake with a website. The page never loads, and the error points at cipher suites, the algorithms a browser and a server use to encrypt a connection between them.

The name only tells half the story. Firefox reports this error in several situations that have nothing to do with cipher suites, which is why the common advice to start editing encryption settings so rarely helps. This guide explains what the error actually means, what causes it in practice, and how to fix it both as a visitor and as the owner of the site.

Quick answer:

SSL_ERROR_NO_CYPHER_OVERLAP means Firefox could not agree on encryption terms with a server, but it is also a catch-all. NSS, the TLS library inside Firefox, reports this exact error for any fatal handshake_failure alert a server sends in reply to the ClientHello, whatever the server’s real reason was. So the error usually means “the server rejected my connection request”, not literally “we share no cipher”.

The most common causes are TLS-inspecting antivirus or corporate proxy software on the visitor’s machine, Firefox cipher preferences edited by hand in about:config, and a server that offers only obsolete cipher suites or a certificate key type the client cannot use. Visitors should turn off HTTPS scanning in their security software and reset any bolded entries in about:config. Site owners should enable TLS 1.2 and TLS 1.3 with a current cipher list.

What Is the SSL_ERROR_NO_CYPHER_OVERLAP Error?

SSL_ERROR_NO_CYPHER_OVERLAP is a Firefox error code that appears on a “Secure Connection Failed” page. It means the TLS handshake ended before any page content could be transferred, so Firefox has nothing to display.

Every HTTPS connection starts with a negotiation. Your browser sends a message called the ClientHello that lists the TLS versions it supports and the cipher suites it is willing to use. The server picks one combination from that list and replies. If the server finds nothing in the list it can accept, there is no overlap, the handshake stops, and Firefox reports this error.

The spelling is deliberate. Mozilla writes it as CYPHER with a Y in the error constant itself, so it is not a typo on this page or in your browser.

The error is specific to Firefox and other applications built on Mozilla’s TLS library. Other browsers report the same class of failure under different names. In Chrome and other Chromium browsers such as Edge, Brave, and Opera, you will see ERR_SSL_VERSION_OR_CIPHER_MISMATCH instead. If a site fails in Firefox with this error but loads in Chrome, that difference is a useful diagnostic on its own, and the section on fixing it as a visitor explains how to use it.

Why the Error Name Is Often Misleading

This is the part most troubleshooting guides miss, and it changes how you should read the error.

Firefox does not implement TLS itself. It uses Network Security Services (NSS), Mozilla’s cryptography library. Inside the NSS alert handler, in the file lib/ssl/ssl3con.c, there is a shortcut that the developers documented in the code comment:

if ((ss->ssl3.hs.ws == wait_server_hello) &&
    (desc == handshake_failure)) {
    /* XXX This is a hack.  We're assuming that any handshake failure
     * XXX on the client hello is a failure to match ciphers.
     */
    error = SSL_ERROR_NO_CYPHER_OVERLAP;
}

In plain terms: when Firefox has sent its ClientHello and is waiting for the server’s reply, any fatal handshake_failure alert that arrives gets relabelled as SSL_ERROR_NO_CYPHER_OVERLAP. NSS discards whatever the alert originally meant and substitutes the cipher error.

That matters because servers send handshake_failure for many reasons besides cipher suites:

• No cipher suite in common, the literal meaning of the error.
• No signature algorithm in common, which is a separate negotiation from the cipher suite.
• No supported elliptic curve or key exchange group in common.
• A hostname the server does not recognise in the SNI extension.
• A firewall, WAF, or rate limiter rejecting the connection at the TLS layer.

Read the error as “the server refused my connection request” and you will be right far more often than if you read it as “we have no cipher in common”.

NSS does also raise the error genuinely, on paths where Firefox itself detects the mismatch instead of being told by the server. The clearest case is a server that selects a cipher suite Firefox never offered, or one NSS does not implement at all, which Firefox rejects on its own. A missing key exchange group ends in the same error too, though there it is normally the server that notices and answers with a handshake failure, which puts you back on the relabelling path above. Either way, the error text alone will not tell you which of the two happened.

The practical consequence: do not start by editing cipher settings. Start by working out which side is refusing, and why.

What Causes the SSL_ERROR_NO_CYPHER_OVERLAP Error?

These are the causes that actually produce the error, ordered by how often they turn out to be responsible.

1. Security software that inspects HTTPS traffic

This is the most common cause and the one most guides leave out. Antivirus and endpoint security products with an HTTPS scanning feature do not simply watch your traffic, they terminate it. The product intercepts the connection locally, presents its own certificate to Firefox, then opens a second, separate TLS connection to the website on your behalf.

The consequence is that the website never sees Firefox’s cipher list. It sees the security product’s list, which is often narrower, older, or missing support for a modern curve or signature algorithm. When the website rejects that list, the failure travels back to Firefox, which reports SSL_ERROR_NO_CYPHER_OVERLAP even though Firefox’s own configuration is fine.

Products that do this include Avast and AVG (HTTPS Scanning), Bitdefender (Encrypted Web Scan), ESET (SSL/TLS filtering), and Kaspersky (encrypted connections scanning). Corporate networks do the same thing at the gateway with a TLS-inspecting proxy or DPI appliance, which is why this error often appears only on a work laptop or only on the office network.

2. Firefox cipher preferences edited by hand

Firefox exposes individual cipher suites as preferences in about:config. If you or a guide you followed disabled some of them, Firefox will offer a shorter list than it should, and servers with a restricted configuration of their own may then find nothing acceptable in it.

This is self-inflicted and easy to reverse, and the fix is covered below. It is worth checking early on any profile that has been carried across several Firefox versions.

3. A server that offers only obsolete cipher suites or protocols

Some servers, especially internal appliances, old management interfaces, and hardware that has not been updated in years, still offer only legacy suites built on RC4, 3DES, or CBC with SHA-1, and sometimes only TLS 1.0 or TLS 1.1.

Firefox no longer negotiates those. Its minimum protocol version defaults to TLS 1.2, and SSL 3.0 has been disabled by default since Firefox 34 in December 2014, after the POODLE attack. A server still limited to those protocols has nothing Firefox will accept. Note that if the version is the specific problem, Firefox often reports SSL_ERROR_UNSUPPORTED_VERSION or SSL_ERROR_PROTOCOL_VERSION_ALERT instead, so an outdated protocol is a narrower cause than the old advice suggests.

4. The certificate key type does not match the offered suites

In TLS 1.2, the cipher suite includes the authentication algorithm, so the certificate’s key type and the cipher suite are linked. A server holding an ECDSA certificate can only complete the handshake with an ECDHE_ECDSA suite. If the client offers RSA suites only, there is genuinely no overlap, even though both sides support strong modern cryptography.

This is the real reason the error sometimes follows Cloudflare-hosted sites. Universal SSL on Cloudflare’s Free plan issues an ECDSA-only certificate. Cloudflare’s own documentation states that for zones on the Free plan, Universal SSL is only compatible with browsers that support ECDSA, while paid plans also serve an RSA certificate. Any client, or any intercepting middlebox acting on its behalf, that offers no ECDSA-capable suites will hit exactly this error on a free-plan Cloudflare site.

You will also find advice blaming this error on Firefox lacking support for the SNI protocol with Cloudflare. That is not the mechanism. Firefox has sent SNI since Firefox 2 in 2006. Cloudflare does require SNI, but the clients that lack it are roughly two decades out of date, not current Firefox. The certificate key type above is the Cloudflare-specific cause worth checking.

5. No shared elliptic curve

Key exchange needs an agreed named group, and you get this same error when the browser and the server have no group in common. It is uncommon on the public web, where the standard curves are near universal, but it does appear on servers restricted to a single unusual curve and on devices with hardware crypto that supports only one.

What Does Not Cause This Error

Several fixes circulate widely for this error that cannot affect it. Knowing what to skip saves time.

An expired SSL certificate

An expired certificate produces SEC_ERROR_EXPIRED_CERTIFICATE in Firefox, not this error, and it comes with an option to view the certificate and continue. Certificate validation happens after the cipher suite has already been agreed, so a handshake that fails on cipher negotiation never reaches the point where expiry is checked.

Clearing the browser cache and cookies

The TLS handshake happens before any HTTP request is sent, so cached pages and cookies are not involved. Clearing them is harmless, but it will not resolve a handshake that never completed. The one related item that does matter is the TLS session cache, and restarting Firefox clears that.

Disabling browser extensions

WebExtensions have no API that can alter the TLS cipher list, so no ordinary add-on can cause or fix this error. There is one indirect exception: an extension that routes your traffic through a proxy or VPN changes which client actually connects to the site, and that proxy can trigger the error. If you use one, turn it off as part of the first diagnostic step rather than working through your add-ons one at a time.

How to Fix SSL_ERROR_NO_CYPHER_OVERLAP as a Visitor

Work through these in order. The first step tells you whether there is anything you can fix at all, which saves you from changing settings that were never the problem.

1. Find out whether the problem is on your side

Try the same address in this order:

1. In another browser on the same computer, such as Chrome or Edge.
2. On a different device on the same network.
3. On a phone using mobile data rather than Wi-Fi, which takes your network entirely out of the picture.

If the site fails everywhere, including on mobile data, the server is the problem and there is no browser setting that will fix it. Confirm it with our free SSL Checker, which reports the protocols and cipher suites the server offers, then report the result to the site owner.

If it fails only in Firefox, or only on one machine, or only on one network, the cause is local and the next steps apply. Firefox’s Troubleshoot Mode is a fast way to narrow it further: open the application menu, choose Help, then Troubleshoot Mode. Troubleshoot Mode disables add-ons but keeps your preferences, so a site that works there points at a proxy add-on, while a site that still fails points at your preferences or at software outside Firefox.

2. Turn off HTTPS scanning in your security software

If the error is local, this is the first thing to test, because TLS interception is the most frequent cause. The setting is usually named after encrypted or SSL traffic:

• Bitdefender: open Protection, then Online Threat Prevention, open its settings, and turn off Encrypted Web Scan.
• Avast: open Menu, then Settings, go to Scam Guardian and Web Guard, which recent versions renamed from Web Shield, and turn off Enable HTTPS scanning.
• AVG: open Menu, then Settings, go to Basic protection and Web Shield, and turn off Enable HTTPS scanning.
• ESET: open Advanced setup, go to Protections, then SSL/TLS, and turn off Enable SSL/TLS.
• Kaspersky: open Settings, go to Security settings and Network settings, and select Do not scan encrypted connections.

Reload the site. If it works, you have found the cause. Update the security product to its current version and turn the feature back on, since these cipher lists are usually fixed in later releases. If the site still fails with the feature on after updating, add an exclusion for that site rather than leaving HTTPS scanning off permanently, and report the site to the vendor.

On a managed work computer, the interception often happens at the network gateway rather than on your machine, and the settings are not yours to change. In that case the fix belongs to your IT team.

3. Reset any Firefox security settings that were changed

The goal here is to put Firefox’s encryption settings back to their defaults, not to tune individual cipher suites. Firefox makes this straightforward, because it marks every preference that differs from its default:

1. Type about:config in a new tab and accept the warning.
2. Search for tls. Any entry shown in bold has been modified from its default value.
3. Click the Reset button at the end of each bolded row. Firefox only offers Reset on modified preferences, so unbolded entries need nothing.
4. Repeat the search for ssl3 and reset any bolded entries there too.
5. Restart Firefox and reload the site.

Two warnings, because both of these appear in older troubleshooting advice and both make things worse.

Do not set individual cipher preferences to true or false by hand. A widely copied instruction tells readers to set these two preferences to false:

• security.ssl3.dhe_rsa_aes_128_sha
• security.ssl3.dhe_rsa_aes_256_sha

Both already ship as false in current Firefox, so following that step changes nothing at all. The reverse, setting them to true, does have an effect, and it is a bad one: those are DHE suites using CBC mode with SHA-1, disabled on purpose after the Logjam weakness in Diffie-Hellman key exchange. Enabling them weakens your browser for every site and almost never fixes the error.

Do not lower security.tls.version.min. Its default value of 3 means TLS 1.2. Setting it to 1 or 2 re-enables TLS 1.0 and TLS 1.1 for every site you visit in order to reach one server that has not been updated. If a single internal appliance genuinely requires it, use a separate browser profile for that device rather than downgrading your everyday browsing.

4. Update Firefox

Support for cipher suites, signature algorithms, and curves changes between Firefox releases, and a version several years old can genuinely lack something a modern server requires. Open the application menu, choose Help, then About Firefox, and let any pending update install.

If the error survives all four steps and the site also fails on mobile data, the problem is the server. The rest of this guide is what needs to happen there.

How to Fix SSL_ERROR_NO_CYPHER_OVERLAP as a Website Owner

If visitors report this error on your site, measure the server’s configuration before changing it. Because of the catch-all described earlier, the cause may not be cipher suites at all.

1. Check what your server actually offers

Start with a single handshake to see which protocol and suite are negotiated:

openssl s_client -connect example.com:443 -servername example.com

Read the line beginning New, near the end of the output, which names the negotiated protocol and cipher. A separate SSL-Session block with its own Protocol and Cipher lines is printed only when the connection settled on TLS 1.2 or below, or when a TLS 1.3 session ticket arrives, so its absence is not a failure. To enumerate everything the server will accept rather than just the one it picked, use Nmap:

nmap --script ssl-enum-ciphers -p 443 example.com

A scan with our SSL Checker gives you the same picture from the outside without installing anything, along with the certificate chain and any configuration problems the browser padlock will not show you.

2. Enable TLS 1.2 and TLS 1.3 with a current cipher list

If the scan shows only legacy suites, or a list trimmed down to one or two entries, replace it with a modern set. The lists below follow Mozilla’s intermediate configuration, which supports current browsers while keeping compatibility back to roughly Firefox 27 and Chrome 31.

For Apache, in your SSL virtual host or in the global SSL configuration:

SSLProtocol             -all +TLSv1.2 +TLSv1.3
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder     off
SSLSessionTickets       off

Test the configuration before reloading, so a typo cannot take the site down:

sudo apachectl configtest
sudo systemctl reload apache2

For Nginx, in the server block that terminates TLS:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

Again, test first, then reload:

sudo nginx -t
sudo systemctl reload nginx

Those cipher lists apply to TLS 1.2 and below. TLS 1.3 replaces them with a short fixed set of its own, and both servers enable it by default when built against OpenSSL 1.1.1 or newer, so there is nothing to configure there.

One caution in the other direction: over-trimming causes this error as reliably as leaving legacy suites in place. A configuration cut back to a single suite will fail for any client that does not support that exact one. Keep the full intermediate list unless you have a specific reason not to.

3. Match the certificate key type to the suites you offer

Check which key your certificate uses:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep "Public Key Algorithm"

If it reports id-ecPublicKey, you are serving an ECDSA certificate, and only the ECDHE_ECDSA suites in the list above can be used with it. A client that offers RSA suites only will fail, which is what the error is telling you.

Both Apache and Nginx can serve an RSA and an ECDSA certificate at the same time, by listing two certificate and key pairs in the same virtual host or server block. The server then presents whichever one the client can use. That removes this class of failure without giving up ECDSA.

If your site is behind Cloudflare on the Free plan, Universal SSL serves an ECDSA-only certificate at the edge. Upgrading the zone to a paid plan adds an RSA certificate alongside it, and uploading a custom certificate is the other route. This matters only if a meaningful share of your visitors sit behind old clients or RSA-only inspection proxies.

4. Rule out rejections that have nothing to do with ciphers

If your cipher configuration checks out and visitors still report the error, remember that Firefox relabels any rejection of the ClientHello as a cipher problem. Look at what else could be refusing the connection:

• A WAF, IP reputation service, or rate limiter dropping connections at the TLS layer before any HTTP request exists to log.
• A virtual host that answers the wrong hostname, so the SNI value in the ClientHello matches nothing you serve.
• Client certificate authentication required on a host where you did not intend it.
• A load balancer or reverse proxy in front of the origin with its own, older TLS configuration.

The server’s error log during the failing period is the fastest confirmation. If your origin sits behind Cloudflare and the failure is on the Cloudflare-to-origin leg rather than the browser-to-Cloudflare leg, you will see Cloudflare error 525 instead, which is a different problem with a different fix.

5. Keep the TLS stack updated

Which suites and curves exist at all is decided by your OpenSSL version and your web server build, not only by your configuration file. A server running an OpenSSL release that predates TLS 1.3 cannot offer it however you configure it. Keep Apache, Nginx, or IIS and their underlying SSL or TLS libraries patched, and re-run the scan afterwards to confirm the negotiated protocol changed.

Frequently Asked Questions

For more SSL error troubleshooting, check our detailed tutorials about fixing different SSL errors.