SSL_ERROR_NO_CYPHER_OVERLAP: Real Fix Guide

Quick answer: SSL_ERROR_NO_CYPHER_OVERLAP means the TLS handshake failed because neither side has a cipher suite the other will accept — the fix is almost always on the server's TLS config, not your browser.

What's actually happening here is a negotiation breakdown during the TLS handshake. Your browser sends a ClientHello listing every cipher suite it supports, the server replies with its own list, and if the two sets have zero overlap, the handshake dies with that error. Modern Firefox (v120+) and Chrome (v120+) have dropped a lot of legacy ciphers — RC4, 3DES, static RSA key exchange. If you're hitting an old appliance, an internal server with a stale OpenSSL build, or a vendor box nobody's patched since 2018, you'll see this constantly. Same thing happens in reverse: someone hardens a new server with only TLS 1.3 ciphers, and an ancient client on Windows 7 can't find a match.

Here's the thing — this error is diagnostic gold. It tells you the connection reached the server and the server is listening on 443. You don't have a DNS problem, you don't have a firewall block. You've got a config mismatch.

Confirm it before you touch anything

Run this from a Linux box or WSL. It'll show you exactly what cipher suites the server will agree to:

openssl s_client -connect example.com:443 -tls1_2 2>/dev/null | grep -A1 "Cipher is"
openssl s_client -connect example.com:443 -tls1_3 2>/dev/null | grep -A1 "Cipher is"

If TLS 1.3 works and 1.2 doesn't, your server has skipped modern ciphers on the older protocol. If both fail with no ciphers available, the server's config is broken across the board. That's your evidence — bring it to whoever runs the box.

Fix it — numbered steps

Get the server's current cipher list. For nginx, run nginx -T 2>/dev/null | grep ssl_ciphers. For Apache, check SSLCipherSuite in your vhost config. For IIS, it's in the registry under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers. If the list is short or full of RC4/3DES entries, that's the problem.
Replace the cipher list with a modern, sane set. For nginx, drop this into your server block:

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';
ssl_prefer_server_ciphers off;

Every one of those suites is supported by Firefox 120+, Chrome 120+, Edge 120+, and Safari 17. Order matters when ssl_prefer_server_ciphers is on — leave it off and let the client pick, which reduces handshake latency on modern hardware.

Reload the server. nginx -s reload or systemctl reload apache2. Don't restart — reload picks up the config without dropping live connections.
Retest with openssl. Run the same s_client command from earlier. You should now see a cipher name in the output like TLS_AES_128_GCM_SHA256 or ECDHE-RSA-AES128-GCM-SHA256. If it still fails, you edited the wrong config file — check for a default server block that's intercepting.
Hard-refresh the browser. Firefox caches failed TLS state per-host. Close every tab to that domain, or open about:networking#dns and clear the cache. Chrome users should hit chrome://net-internals/#sockets and flush socket pools.

If that doesn't work

Sometimes you can't change the server — a vendor appliance, an embedded device, an old piece of industrial gear with a web UI from 2014. Your options in that case:

Use a browser that still ships legacy ciphers. Firefox ESR 102 has a longer cipher list than mainline Firefox, though it's end-of-life. Pale Moon and Basilisk keep older suites enabled. Not ideal, but sometimes it's the only path to a device UI.
Re-enable legacy ciphers in Firefox manually. In about:config, search for security.tls.version.enable-deprecated and set it to true. This re-enables TLS 1.0 and 1.1. Understand the tradeoff: you're deliberately downgrading your own security to talk to a broken device. Do it in a separate profile, not your daily driver.
Put a reverse proxy in front of it. This is the real fix. Run nginx or Caddy on a modern box, have it terminate TLS with a proper cipher suite, and proxy plain HTTP to the old device on your internal network. The old device never sees TLS. Caddy does this in about four lines of config and handles cert renewal automatically.

Prevention

Pin your TLS config in version control and test it after every OpenSSL upgrade. The Mozilla SSL Configuration Generator at ssl-config.mozilla.org spits out current recommendations for nginx, Apache, HAProxy, and AWS ALB — regenerate your config yearly or whenever you bump a major OpenSSL version. Subscribe to the Mozilla and Chrome security blogs too; when they announce cipher removal, it lands in stable about six weeks later, and that's your window to catch stragglers before users start filing tickets.