How to Fix ERR_SSL_VERSION_OR_CIPHER_MISMATCH

ERR_SSL_VERSION_OR_CIPHER_MISMATCH is the message Chrome shows when it cannot agree on encryption terms with a website. The handshake ends before any page content is sent, so there is nothing to display and no option to continue anyway.

You may also encounter variations of this error:

• Error 113 (net::err_ssl_version_or_cipher_mismatch): unknown error
• The client and server don’t support a common SSL protocol version or cipher suite

That second line is not a paraphrase. It is the comment Chromium’s own source code attaches to error number 113, which is why it turns up word for word in so many places.

Quick answer:

ERR_SSL_VERSION_OR_CIPHER_MISMATCH means Chrome and the server could not agree on a TLS version or a cipher suite, so the handshake stopped before any content moved. Chromium raises it for a short, specific list of conditions: no cipher suite in common, an insufficient_security or protocol_version alert from the server, a protocol version Chrome no longer supports (TLS 1.0 and TLS 1.1 since Chrome 84), and a handshake_failure alert sent in reply to the ClientHello. It is not a certificate name-mismatch error, which is ERR_CERT_COMMON_NAME_INVALID and shows a warning page you can click through.

Site owners should enable TLS 1.2 and TLS 1.3 with a current cipher list, and on Cloudflare check that the certificate has finished activating, that the DNS record is proxied, and that the hostname is not a multi-level subdomain Universal SSL does not cover. Visitors should turn off HTTPS scanning in their security software, because very little else on the client side can produce this error.

What Is the ERR_SSL_VERSION_OR_CIPHER_MISMATCH Error?

Every HTTPS connection opens 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 nothing in the list is acceptable, there is no overlap, the TLS handshake stops, and Chrome reports this error.

One detail separates this error from most SSL warnings you have seen. Certificate problems, such as an expired or wrongly named certificate, produce a red interstitial with an Advanced link and a Proceed option, because the connection itself was established and only the identity check failed. ERR_SSL_VERSION_OR_CIPHER_MISMATCH has no such option. The encrypted channel was never built, so there is nothing to proceed into.

The error appears in every Chromium-based browser, so Edge, Brave, Opera, and Vivaldi show the same message for the same reason. Firefox reports this class of failure as SSL_ERROR_NO_CYPHER_OVERLAP instead, and the two do not cover quite the same ground. That difference is a useful diagnostic in its own right, and it has its own section below.

What Actually Triggers This Error in Chrome

Most troubleshooting guides list causes by guesswork. You do not have to, because Chromium is open source and the mapping is written down. A single function decides which network error a failed handshake becomes, and only five conditions produce this one directly:

case SSL_R_NO_CIPHER_MATCH:
case SSL_R_NO_SHARED_CIPHER:
case SSL_R_TLSV1_ALERT_INSUFFICIENT_SECURITY:
case SSL_R_TLSV1_ALERT_PROTOCOL_VERSION:
case SSL_R_UNSUPPORTED_PROTOCOL:
  return ERR_SSL_VERSION_OR_CIPHER_MISMATCH;

Read plainly, those five are:

• No cipher match and no shared cipher: the two sides genuinely have no cipher suite in common.
• insufficient_security: the server received the ClientHello and judged the offered parameters too weak, so it refused on security grounds.
• protocol_version: the server rejected the TLS version Chrome proposed.
• unsupported protocol: Chrome itself refused, because the version the server wants falls outside what Chrome still accepts.

There is a sixth path, and it is the one that makes this error so much broader in practice than its name suggests. A handshake_failure alert is the generic “no” a server sends when it does not want to explain itself. Chromium relabels it as a cipher mismatch, but only under one condition, and the developers documented why in the code comment:

// SSL_R_SSLV3_ALERT_HANDSHAKE_FAILURE may be returned from the server after
// receiving ClientHello if there's no common supported cipher. Map that
// specific case to ERR_SSL_VERSION_OR_CIPHER_MISMATCH to match the NSS
// implementation.
case SSL_R_SSLV3_ALERT_HANDSHAKE_FAILURE: {
  uint32_t previous = ERR_peek_error();
  if (previous != 0 && ERR_GET_LIB(previous) == ERR_LIB_SSL &&
      ERR_GET_REASON(previous) == SSL_R_HANDSHAKE_FAILURE_ON_CLIENT_HELLO) {
    return ERR_SSL_VERSION_OR_CIPHER_MISMATCH;
  }
  return ERR_SSL_PROTOCOL_ERROR;
}

In other words: if the server rejects the ClientHello with a generic refusal, Chrome guesses that ciphers were the reason and shows this error. If the same alert arrives at any other point in the handshake, you get ERR_SSL_PROTOCOL_ERROR instead. Chromium adopted the guess deliberately, to match how Firefox’s TLS library had already been behaving.

The practical consequence matters more than the mechanism. Servers send handshake_failure for reasons that have nothing to do with cipher suites: no signature algorithm in common, no shared elliptic curve, a WAF or rate limiter dropping the connection, or a virtual host that does not recognise the name you asked for. All of those can surface as ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Read the error as “the server refused my connection request” and you will be right more often than if you read it literally.

What Does Not Cause This Error

Several fixes circulate widely for this error that cannot affect it. Ruling them out first saves time.

A certificate name mismatch

This is the most common misdiagnosis, and it is worth being precise about because a lot of advice starts here. A certificate issued for the wrong hostname produces ERR_CERT_COMMON_NAME_INVALID, error number 200, which sits in Chrome’s certificate error range and appears as a warning page with an option to continue.

The reason it cannot be this error is a matter of sequence. The certificate is checked after the cipher suite and protocol version have already been agreed. A handshake that fails during negotiation never reaches the point where the name on the certificate is examined. If you can see certificate details and click through to the site, you are looking at a different problem.

An expired SSL certificate

Same sequence, same conclusion. An expired certificate produces ERR_CERT_DATE_INVALID, another interstitial you can click through, not a negotiation failure.

Chrome’s QUIC protocol

A widely copied instruction tells readers to open chrome://flags and disable Experimental QUIC Protocol. The flag exists, but it does not address this error. QUIC failures have their own network error, ERR_QUIC_PROTOCOL_ERROR, number 356, and when a QUIC connection cannot be established Chrome falls back to TCP and TLS on its own. Turning the flag off changes which transport is tried first, not whether Chrome and the server share a cipher suite.

If you have already disabled it while troubleshooting, set it back to Default. Leaving experimental flags switched off across your whole browser to work around one site is a poor trade.

Clearing the browser cache, or the SSL state

The TLS handshake happens before any HTTP request is sent, so cached pages and cookies play no part in it. Clearing them is harmless and will not help.

Clearing the SSL state is a real operation, but it is often described incorrectly. It empties the TLS session cache and any remembered client-certificate choices, not a store of website certificates. Because this error means the handshake never completed, there is no cached session to be at fault. If you want to clear it anyway, follow the current steps in our guide on how to clear the SSL state. Older instructions that tell you to click Show advanced settings in Chrome no longer apply, since that page was redesigned back in 2017.

How Chrome’s Error Differs From Firefox’s SSL_ERROR_NO_CYPHER_OVERLAP

Chrome and Firefox both fold a rejected ClientHello into a single cipher-flavoured error, and Chromium’s code comment says outright that it copied the behaviour from Mozilla’s library. The two are close relatives, but they do not cover quite the same ground, and knowing where they differ turns a browser comparison into a diagnostic.

The ClientHello catch-all is the same size in both. Firefox relabels a handshake_failure alert whenever one arrives while it is still waiting for the server’s reply. Chrome applies the same test: its TLS library marks the alert only when it was read in that same waiting-for-ServerHello state, and the comment beside that code says it was written to match Firefox’s behaviour. So a generic refusal of the ClientHello produces the cipher error in both browsers, and neither catch-all is the wider one. If the same alert arrives later in the handshake, Chrome reports ERR_SSL_PROTOCOL_ERROR and Firefox reports SSL_ERROR_HANDSHAKE_FAILURE_ALERT.

Two cases that look like they should divide the two browsers do not, and it is worth saying so, because plenty of guides assume otherwise. A fatal unrecognized_name alert gets its own code in both browsers, ERR_SSL_UNRECOGNIZED_NAME_ALERT in Chrome and SSL_ERROR_UNRECOGNIZED_NAME_ALERT in Firefox, so neither folds it in here. A missing client certificate likewise gets its own code in both, though they arrive there differently: Chrome notices it was asked for a certificate and had none to send, while Firefox’s relabel simply does not reach that far into the handshake.

The real difference is protocol versions, and this is the useful part. Protocol version problems land in this error in Chrome. An insufficient_security alert, a protocol_version alert, and Chrome’s own refusal of an obsolete version all map here. Chromium made that explicit when it retired its dedicated obsolete-version error, leaving a note in the source that TLS 1.0 and TLS 1.1 now cause ERR_SSL_VERSION_OR_CIPHER_MISMATCH instead. Firefox splits those cases out into SSL_ERROR_UNSUPPORTED_VERSION and SSL_ERROR_PROTOCOL_VERSION_ALERT.

You can use that asymmetry. Open the failing site in both browsers:

• Chrome shows this error, Firefox shows a version error: the protocol version is the problem, not the cipher list. The server is almost certainly still on TLS 1.0 or TLS 1.1.
• Both browsers show their cipher error: the cipher suites, the signature algorithms, or the curves are the problem, or something is refusing the connection outright.
• Only one browser fails: the cause is local to that browser or to software intercepting its traffic, not the server.

What Causes ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

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

1. The server still runs TLS 1.0 or TLS 1.1

This is the single most common reason a site that used to work now fails. Chrome removed support for TLS 1.0 and TLS 1.1 in version 84, released in July 2020, after a deprecation that ran through several earlier releases. Firefox, Safari, and Edge made the same change around the same time.

Both versions had accumulated real weaknesses: they rely on MD5 and SHA-1 in the handshake, and they offer only RC4 and CBC-mode ciphers, both of which have known attacks against them. A server limited to those protocols has nothing current Chrome will accept, and the connection is refused before a certificate is ever examined.

TLS 1.2 and TLS 1.3 are what you need. TLS 1.3 is no longer an upgrade to consider for later: it is standard equipment, supported by roughly three quarters of the top 150,000 sites and negotiated by default in every current browser. Our overview of TLS 1.3 covers what changed and how to enable it.

2. The server offers only obsolete cipher suites

A server can support TLS 1.2 and still fail, if the suites it offers within it are ones Chrome has dropped. RC4 is the classic example: Chrome removed it in version 48, but it persists in enterprise systems and appliances that take longer to upgrade. Suites built on 3DES, or on CBC mode with SHA-1, fall into the same category.

3. A cipher list trimmed too aggressively

The opposite mistake causes the error just as reliably, and it catches people who thought they were doing the right thing. A configuration hardened down to one or two cipher suites will fail for any client that does not support that exact suite. Hardening guides written years ago are a frequent source, since the suite they recommended may since have been deprecated on the client side.

4. Cloudflare certificate and DNS problems

If your site sits behind Cloudflare, the edge certificate is what visitors negotiate against, and Cloudflare documents four distinct causes for this exact error. They are worth checking before you touch any server configuration, because none of them are fixed there.

• The certificate has not activated yet. A newly added domain receives its Universal SSL certificate within 15 minutes to 24 hours. Until it is issued, there is no certificate at the edge to negotiate with. This is the usual explanation when the error appears immediately after a domain is moved to Cloudflare, and waiting is the fix.
• The DNS record is not proxied. Universal and Advanced certificates only cover hostnames proxied through Cloudflare. A record left in DNS-only mode, the grey cloud rather than the orange one, points visitors straight at your origin, which may have no valid certificate of its own.
• A Custom certificate has expired. If you uploaded your own certificate, Cloudflare does not renew it for you. Check its status in the dashboard.
• The hostname is a multi-level subdomain. On a full setup, Universal SSL covers your apex domain and one level of subdomain only. So example.com and www.example.com are covered, while test.dev.example.com is not, and it fails with this error while the rest of the site works. The fix is to enable Total TLS, order an Advanced certificate, or upload a Custom certificate that includes the hostname.

That last one is worth remembering, because it produces the most confusing version of this error: a site where most pages load normally and one subdomain refuses to.

5. 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 other Cloudflare-specific cause, and it is easy to miss. Universal SSL on the Free plan issues an ECDSA-only certificate. Cloudflare’s 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.

6. Security software that inspects HTTPS traffic

This is the main cause that lives on the visitor’s side, and it explains most cases where one machine fails while every other device loads the site normally.

Antivirus and endpoint 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 Chrome, then opens a second, separate TLS connection to the website on your behalf. The website never sees Chrome’s cipher list. It sees the security product’s list, which is often narrower or older. When the website rejects that list, the failure travels back to Chrome, which reports this error even though Chrome’s own configuration is fine.

Corporate networks do the same thing at the gateway with a TLS-inspecting proxy, which is why this error often appears only on a work laptop or only on the office network.

How to Fix ERR_SSL_VERSION_OR_CIPHER_MISMATCH as a Visitor

Be aware that most of the time this error is the site’s problem and not yours. The first step establishes which, so you do not spend time changing settings that were never involved.

1. Find out whether the problem is on your side

Try the same address in this order:

1. In Firefox on the same computer. It uses a different TLS library, and the error name it gives you narrows the cause as described above.
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 no browser setting will fix it. Confirm it with our free SSL Checker, which reports the protocols and cipher suites the server offers, then send the result to the site owner. If it fails only on one machine or one network, the cause is local and the next steps apply.

2. Turn off HTTPS scanning in your security software

If the error is local, test this first. The setting to look for is the one that scans encrypted traffic, not the antivirus as a whole. Leaving your entire security product switched off to load one website is not a reasonable trade, and it is rarely the part that was interfering.

• Bitdefender: open Protection, then Online Threat Prevention, click 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 corrected in later releases. If the site still fails after updating, add an exclusion for that one site rather than leaving HTTPS scanning off permanently.

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

3. Test without your extensions and proxies

Open the site in an Incognito window, which loads without most extensions. If it works there, an extension is involved. In practice it will be one that routes traffic through a proxy or VPN, since no ordinary extension can change Chrome’s cipher list. Turn off any VPN or proxy software as part of this step rather than working through your add-ons one at a time.

4. Update Chrome

Support for cipher suites, signature algorithms, and curves changes between releases. Open the three-dot menu, choose Help, then About Google Chrome, and let any pending update install. Note that updating moves Chrome forward, so it will not restore access to a server that is behind. If the site needs TLS 1.0, a newer Chrome will not fix it and there is no supported setting that will.

One thing to avoid: older guides suggest launching Chrome with command-line flags that re-enable obsolete protocols or ciphers. Those switches have been removed, and where similar ones survive they lower your security for every site you visit in order to reach one that has not been updated. Contact the site owner instead.

How to Fix ERR_SSL_VERSION_OR_CIPHER_MISMATCH as a Website Owner

Measure before you change anything. Because of the catch-all described earlier, the cause may not be cipher suites at all, and editing a working cipher list is an easy way to make things worse.

1. Check what your server actually offers

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

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

Look at the Protocol and Cipher lines near the end of the output. To test whether a specific version is the problem, force it and see whether the connection still completes:

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

If that fails while the server answers on TLS 1.0, you have reproduced exactly what Chrome runs into. To enumerate everything the server will accept rather than just the one combination 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 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 TLS 1.0 or TLS 1.1, only legacy suites, or a list trimmed to one or two entries, replace it. The lists below follow Mozilla’s intermediate configuration, which supports current browsers while keeping reasonable backward compatibility.

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 has its own short, fixed set of cipher suites, and both servers enable the three used in practice by default when built against OpenSSL 1.1.1 or newer, so there is nothing to configure there. Re-run the scan afterwards to confirm the negotiated protocol actually changed.

3. Work through the Cloudflare checklist

If your site is proxied through Cloudflare, check the four causes listed earlier before changing anything on the origin. In the dashboard, confirm the Universal SSL certificate shows as active, that the DNS record for the failing hostname is proxied rather than DNS-only, and that any Custom certificate has not expired.

If only one hostname fails, count its levels. Anything deeper than one level below the apex is outside Universal SSL’s coverage on a full setup, and needs Total TLS, an Advanced certificate, or a Custom certificate. No amount of origin configuration will fix that, because the handshake fails at Cloudflare’s edge before your server is involved.

4. 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.

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, which removes this class of failure without giving up ECDSA. On Cloudflare, upgrading from the Free plan adds an RSA certificate alongside the ECDSA one, and uploading a custom certificate is the other route.

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

If your protocol and cipher configuration checks out and visitors still report the error, remember that Chrome relabels a rejected 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.
• No signature algorithm or elliptic curve in common, which is a separate negotiation from the cipher suite and fails the same way.
• A load balancer or reverse proxy in front of the origin running 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, visitors see Cloudflare error 525 instead, which is a different problem with a different fix.

6. 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.

Frequently Asked Questions

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