SSL_ERROR_NO_CYPHER_OVERLAP and ERR_SSL_VERSION_OR_CIPHER_MISMATCH

SSL_ERROR_NO_CYPHER_OVERLAP in Firefox and ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Chrome mean the same thing: the browser and the server found no protocol version or cipher suite they both accept, so no encrypted connection could start. The cause is almost always the server's configuration, typically one that still offers only old versions or ciphers that browsers have since dropped. The fix is to enable TLS 1.2 and TLS 1.3 with a current cipher list, not to make the browser accept less.

Quick facts

Firefox

Secure Connection Failed, Cannot communicate securely with peer: no common encryption algorithm(s), code SSL_ERROR_NO_CYPHER_OVERLAP

Chrome and Edge

This site can't provide a secure connection, uses an unsupported protocol, code ERR_SSL_VERSION_OR_CIPHER_MISMATCH

What failed

negotiation of the protocol version or cipher suite, before any certificate was sent

Who fixes it

the site owner, in nearly every case

Related

ERR_SSL_PROTOCOL_ERROR, SSL handshake failed

What the error means

Every HTTPS connection begins with a TLS handshake. The browser sends the protocol versions and the cipher suites it supports; the server picks one of each from its own list. When the two lists have nothing in common, the server ends the handshake with an alert and the browser shows this error. The failure comes before the server presents its certificate, so it is unrelated to certificate trust errors such as ERR_CERT_AUTHORITY_INVALID, where the issuer cannot be verified.

Firefox splits the failure in two. SSL_ERROR_NO_CYPHER_OVERLAP means no shared cipher suite, and SSL_ERROR_UNSUPPORTED_VERSION means no shared protocol version. Chrome reports both with one code, which is why its name contains "version or cipher". The diagnosis below tells the two apart.

The usual story is that nothing changed on the server. Browsers remove old versions and ciphers on their own schedule: Chrome no longer supports TLS 1.0 or TLS 1.1, and Firefox turns both off by default. A server configured years ago keeps offering what it always offered, and one browser update later its list no longer overlaps with theirs.

If you are a visitor

The server decides what can be negotiated, so a visitor can rarely fix this. Three checks are worth a minute:

1. Update the browser and the operating system. A very old browser or device may lack the versions a current server requires.

2. Undo changed TLS settings in Firefox. If you or an extension changed preferences starting with security.tls or security.ssl3 on about:config, reset them to their default values. Changed values are shown in bold.

3. Try another network. Antivirus HTTPS scanning, a corporate proxy or a filtering appliance can negotiate on your behalf with its own, older list. If the site works on mobile data, the interference is on the first network.

Do not lower the minimum TLS version in the browser to get past the error. It makes every site you visit accept protocols that were removed for being unsafe, and it leaves the actual problem, the server's configuration, where it was.

If the site fails on another device and another network, only its owner can fix it.

Causes on the server

Only old protocol versions are enabled

The most common cause. The server accepts TLS 1.0 or 1.1 and nothing newer, often because the configuration predates TLS 1.2 becoming the norm, or because the operating system or TLS library is too old to offer it. Firefox reports this as SSL_ERROR_UNSUPPORTED_VERSION and the handshake ends with the protocol_version alert.

Enable TLS 1.2 and TLS 1.3. In nginx:

ssl_protocols TLSv1.2 TLSv1.3;

In Apache:

SSLProtocol -all +TLSv1.2 +TLSv1.3

Where the library cannot offer TLS 1.2 at all, the fix is upgrading it or the operating system, not a configuration line. Details are on TLS versions.

The cipher list contains nothing a browser accepts

The versions match, but every cipher suite the server allows has been removed from browsers: RC4, 3DES, export-grade ciphers and others. This is SSL_ERROR_NO_CYPHER_OVERLAP in its exact sense. Replace the cipher list with a current one rather than adding to the old one. The Mozilla SSL Configuration Generator produces maintained lists for nginx, Apache, HAProxy and other servers, with a choice of how far back client support should reach.

The cipher list does not match the certificate's key

In TLS 1.2, each cipher suite names the kind of key the server must authenticate with. Suites marked ECDSA need a certificate with an ECDSA key, and suites marked RSA need an RSA key. A server whose list contains only ECDSA suites while its certificate has an RSA key has nothing it can actually use, and the handshake fails with no shared cipher even though the list looks modern. Check the key type with openssl x509 -in cert.pem -noout -text and keep suites for that type in the list.

A typo empties the cipher list

Cipher strings are combined with :, + and !, and one mistake can exclude everything. OpenSSL shows what a string actually expands to:

$ openssl ciphers -v 'ECDHE+AESGCM:!aNULL'

An empty result or no cipher match means the server is offering nothing. TLS 1.3 suites are configured separately from this list, so a server with a broken list can still work over TLS 1.3 and fail for every client limited to TLS 1.2.

Something in front of the server

When a load balancer, proxy or CDN terminates connections, its configuration is the one visitors negotiate with. A correct server behind an old front end still produces this error, so check the layer that answers on port 443.

On Windows Server, protocol versions and cipher suites are set for the whole machine in the operating system's TLS component, Schannel, rather than per site in IIS. Changes there need a restart to apply.

How to diagnose

Test from outside, against the hostname visitors use. Offer one version at a time:

$ openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null
$ openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

A working version prints a line such as New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384. A version the server refuses ends with tlsv1 alert protocol version. If both versions are refused, the server needs TLS 1.2 or 1.3 enabled. If TLS 1.2 fails with sslv3 alert handshake failure while the version itself is enabled, the cipher list is the problem.

To list every version and cipher the server accepts, nmap has a script for it:

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

Compare that list with the configuration file. When they differ, another layer is answering, or the server is reading a different file than the one you edited. More commands are on OpenSSL commands.

How to prevent it

This error arrives with browser updates rather than with your changes, so the prevention is periodic review rather than a reaction to reports. Check the versions and ciphers your servers accept once or twice a year, and after any upgrade of the server software, the TLS library or the operating system.

Keep configurations short and current. A cipher list copied from an old guide and extended over the years is the usual source of both kinds of failure: ciphers browsers have dropped, and combinations nobody can read anymore.

FAQ