ERR_SSL_VERSION_OR_CIPHER_MISMATCH: how to fix it

ERR_SSL_VERSION_OR_CIPHER_MISMATCH is a Chrome error that appears when the browser and the server cannot agree on a TLS version or cipher suite for the encrypted connection. The browser wants to use modern encryption. The server is offering something Chrome considers too old or too weak. Neither side will compromise, so the connection fails.

This error is different from certificate errors. The certificate might be perfectly valid – the problem is that the two sides cannot negotiate how to encrypt the connection before they even get to certificate validation.

The error appears in Chrome, Edge, Brave, and other Chromium-based browsers. Firefox shows a similar failure as “SSL_ERROR_NO_CYPHER_OVERLAP.” Safari displays “Safari can’t establish a secure connection.”

What TLS versions and cipher suites are#

Every HTTPS connection requires two negotiations before any data moves:

1. TLS version. The browser and server must agree on which version of the TLS protocol to use. TLS 1.0 and 1.1 are deprecated – all major browsers have disabled them. TLS 1.2 is the current baseline. TLS 1.3 is the latest version and preferred.
2. Cipher suite. Within the agreed TLS version, both sides must agree on a specific combination of cryptographic algorithms for key exchange, authentication, bulk encryption, and message authentication. For example, ECDHE-RSA-AES256-GCM-SHA384 means: ECDHE for key exchange, RSA for authentication, AES-256-GCM for encryption, and SHA-384 for message integrity.

During the TLS handshake, the browser sends a ClientHello message listing every TLS version and cipher suite it supports. The server picks one combination from that list. If there is no overlap – the server only supports versions or ciphers that the browser has removed – the handshake fails and you see ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

How this differs from ERR_SSL_PROTOCOL_ERROR#

Both errors involve TLS handshake failures, but at different stages:

• ERR_SSL_VERSION_OR_CIPHER_MISMATCH means the browser and server could not agree on encryption parameters. The negotiation itself failed. This usually points to an outdated server configuration.
• ERR_SSL_PROTOCOL_ERROR means the TLS handshake broke down for a broader range of reasons – expired certificates, incomplete certificate chains, HTTPS interception by security software, or protocol-level corruption.

In practice, the cipher mismatch error almost always means the server needs updating. The protocol error has a wider set of possible causes on both sides.

Is it the server or your browser?#

Before troubleshooting, determine which side is responsible:

Check with SiteProbe. Use SiteProbe’s SSL checker to inspect the site’s TLS configuration from a neutral location. It shows which TLS versions and cipher suites the server supports. If the checker reports only TLS 1.0/1.1 or weak ciphers, the server is the problem.

Try a different browser. Open the same URL in Firefox. If Firefox also fails (with “SSL_ERROR_NO_CYPHER_OVERLAP”), the problem is the server. If Firefox works, something on your Chrome installation or device is interfering.

Try a different device. If the site loads on your phone but not your laptop, the issue is your device’s configuration – usually security software intercepting HTTPS.

Try a different network. Corporate networks and public Wi-Fi sometimes use SSL inspection proxies that can cause cipher mismatch errors. Switch to mobile data and test.

Server-side causes and fixes#

The server side is responsible in the majority of ERR_SSL_VERSION_OR_CIPHER_MISMATCH cases. These are fixes for site owners and server administrators.

The server only supports TLS 1.0 or 1.1

This is the most common cause. Chrome disabled TLS 1.0 and 1.1 in early 2020. Firefox, Safari, and Edge followed. If a server only accepts these deprecated versions, no modern browser can connect to it.

How to check: SiteProbe’s SSL checker shows which TLS versions the server supports. If the results show only TLS 1.0 or 1.1, that is the problem.

How to fix: Update the server’s TLS configuration to support TLS 1.2 and TLS 1.3. The exact method depends on your web server.

For Nginx, in the http or server block:

ssl_protocols TLSv1.2 TLSv1.3;

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

SSLProtocol -all +TLSv1.2 +TLSv1.3

Restart the web server after making changes and verify with SiteProbe.

The server only supports weak or deprecated cipher suites

Even with TLS 1.2 enabled, the server might only offer cipher suites that Chrome has deprecated. Chrome requires forward secrecy (ECDHE or DHE key exchange) and AEAD ciphers (GCM or CHACHA20-POLY1305). Older ciphers like RC4, 3DES, CBC-mode without AEAD, or cipher suites without forward secrecy are rejected.

How to check: The SiteProbe SSL checker lists the cipher suites the server supports. If you see entries like RC4-SHA , DES-CBC3-SHA , or cipher suites without ECDHE or DHE in the name, those are the problem.

How to fix: Configure the server to use modern, AEAD-only cipher suites with forward secrecy.

For Nginx:

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 on;

For Apache:

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
SSLHonorCipherOrder on

This cipher list provides broad compatibility with every modern browser while excluding everything deprecated. TLS 1.3 cipher suites are negotiated separately by the protocol and do not need to be listed in ssl_ciphers – they are always used when both sides support TLS 1.3.

The certificate uses SHA-1 signing

Chrome has rejected SHA-1 signed certificates since 2017. If the server’s certificate or any intermediate certificate in the chain uses SHA-1, Chrome will refuse the connection.

How to check: Inspect the certificate details in SiteProbe or in the browser’s certificate viewer. Look at the “Signature Algorithm” field. If it says sha1WithRSAEncryption , that is the problem.

How to fix: Obtain a new certificate. Every modern Certificate Authority issues SHA-256 certificates by default. If you are using Let’s Encrypt, your certificates are already SHA-256 – this issue only affects very old commercial certificates that were never renewed. For more on certificate types, see free vs paid SSL certificates.

Certificate and domain name mismatch

If the certificate’s Common Name (CN) or Subject Alternative Names (SANs) do not include the domain you are accessing, Chrome may show ERR_SSL_VERSION_OR_CIPHER_MISMATCH instead of the more specific NET::ERR_CERT_COMMON_NAME_INVALID. This happens most often when:

• Visiting  www.example.com  but the certificate only covers  example.com  (or vice versa)
• Visiting a subdomain not included in the certificate
• The server is using a default or fallback certificate meant for a different domain

How to check: SiteProbe shows the domains covered by the certificate. Compare them to the URL you are trying to access.

How to fix: Obtain a certificate that covers the correct domain. If you need both example.com and www.example.com , the certificate must include both as SANs. Let’s Encrypt includes both automatically when you request the certificate correctly. For wildcard coverage ( *.example.com ), you need a wildcard certificate issued via DNS validation.

Outdated web server software

Very old versions of web server software (Nginx, Apache, IIS, or the underlying OpenSSL/LibreSSL library) may not support TLS 1.2 or modern cipher suites at all, regardless of configuration.

• OpenSSL 1.0.1 (2012) added TLS 1.2 support
• OpenSSL 1.1.1 (2018) added TLS 1.3 support
• Nginx 1.13.0 (2017) added TLS 1.3 support
• Apache 2.4.36 (2018) added TLS 1.3 support (with OpenSSL 1.1.1)

If you are running software older than these versions, no configuration change will help – you need to upgrade the server software itself.

Check your OpenSSL version:

openssl version

Check your Nginx version:

nginx -v

CDN or proxy misconfiguration

If your site is behind a CDN (like Cloudflare) or a reverse proxy, the TLS configuration that browsers see is the CDN’s configuration, not your origin server’s. A cipher mismatch error in this case means the CDN’s TLS settings need adjustment, not your origin server’s.

Check where the domain’s DNS actually points. If it points to a CDN, log into the CDN’s dashboard and check its TLS settings. Most CDNs default to modern TLS configurations, but custom settings or legacy plans may have outdated defaults.

Also check the connection between the CDN and your origin server. If the CDN requires TLS 1.2+ to reach your origin but your origin only supports TLS 1.0, the CDN will return an error to the browser even though the CDN’s own TLS configuration is fine.

Client-side causes and fixes#

If SiteProbe shows a valid certificate with modern TLS support and the error only appears on your device, the problem is on your end.

Outdated operating system

The TLS implementation in your browser depends partly on the operating system’s cryptographic libraries. Very old operating systems may not support TLS 1.2 or the cipher suites the server requires.

• Windows XP does not support TLS 1.2 in Internet Explorer or system libraries
• Windows 7 supports TLS 1.2 but it is disabled by default in some configurations
• Android 4.x and earlier have limited TLS 1.2 support
• macOS 10.12 (Sierra) and earlier may have limited cipher suite support

How to fix: Update your operating system. If you are on an operating system that no longer receives updates, this is a strong signal to upgrade – the TLS incompatibility is one symptom of a broader security problem.

For Windows 7 specifically, TLS 1.2 may need to be enabled manually in the registry or Internet Options:

1. Open Internet Options (search in Start menu)
2. Go to the Advanced tab
3. Scroll to the Security section
4. Ensure “Use TLS 1.2” is checked
5. Click OK and restart the browser

Antivirus or security software intercepting HTTPS

Security software that performs HTTPS inspection inserts itself between the browser and the server, using its own certificate and its own TLS configuration. If the software’s TLS implementation is outdated or misconfigured, it can create a cipher mismatch between itself and the server even though your browser and the server would have negotiated successfully without the interception.

How to test: Temporarily disable your antivirus or security software and try the connection. If the error disappears, the security software is the cause.

Common culprits:

• Avast and AVG (HTTPS scanning)
• Kaspersky (encrypted connections scanning)
• ESET (SSL/TLS protocol filtering)
• Corporate VPNs with SSL inspection
• Zscaler, Forcepoint, and other enterprise security proxies

How to fix: Either disable HTTPS scanning in the security software’s settings (usually under Web Protection or Network settings) or update the software to its latest version, which may include updated TLS support.

Browser cache and stale SSL state

Chrome caches TLS session data to speed up reconnections. If a server recently updated its TLS configuration, Chrome may try to resume a session using the old parameters, causing a mismatch.

How to fix:

1. Clear Chrome’s browsing data: go to  chrome://settings/clearBrowserData , select “Cached images and files” and “Cookies and other site data”, then clear
2. Flush Chrome’s socket pools: go to  chrome://net-internals/#sockets  and click “Flush socket pools”
3. Delete domain security policies: go to  chrome://net-internals/#hsts , enter the domain under “Delete domain security policies” and click Delete
4. Close and reopen Chrome

QUIC protocol interference

Chrome uses the QUIC protocol (HTTP/3) for connections to sites that support it. QUIC runs over UDP instead of TCP, and some networks block or interfere with UDP traffic on port 443. When QUIC fails, Chrome sometimes reports it as a cipher mismatch rather than gracefully falling back to TCP.

How to test: Disable QUIC temporarily:

1. Go to  chrome://flags/#enable-quic
2. Set it to Disabled
3. Relaunch Chrome

If the error disappears, the issue is QUIC-related. This usually means a firewall or network device is blocking UDP on port 443. Re-enable QUIC after testing – the fix should be applied at the network level, not in Chrome.

Fixing the error on Android#

On Android, ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Chrome has the same root causes but different troubleshooting steps.

Update Chrome. Open the Play Store, search for Chrome, and install any available updates. Older Chrome versions on Android may lack support for the cipher suites the server requires.

Update Android. Go to Settings > System > System update. Older Android versions (4.x and early 5.x) have limited TLS 1.2 and cipher suite support. If your device is too old to receive updates, this is a hardware limitation.

Clear Chrome data. Go to Settings > Apps > Chrome > Storage > Clear Cache, then Clear Data. Reopen Chrome and try again.

Check VPN or proxy apps. VPN apps that route all traffic through their servers may use outdated TLS configurations. Disable any VPN and test the connection directly.

Try a different network. If the error only appears on Wi-Fi (especially corporate or public Wi-Fi), the network may be using an SSL inspection proxy with outdated TLS support. Switch to mobile data and test.

The "bypass" question#

Searching for “ERR_SSL_VERSION_OR_CIPHER_MISMATCH bypass” is common but misleading. Unlike some certificate errors where Chrome shows a “Proceed anyway” option, this error has no bypass button. Chrome will not let you click through it.

This is intentional. A cipher mismatch means the browser and server literally cannot establish encryption. There is no degraded connection to accept – there is no connection at all. Chrome cannot show you the page because it has no way to communicate with the server securely, and it will not communicate insecurely.

The only way past this error is to fix the underlying cause: update the server’s TLS configuration, update your browser or operating system, or remove whatever is interfering with the connection.

Diagnosing with command-line tools#

If you need more detail than SiteProbe provides, OpenSSL’s command-line tools can show exactly what the server supports.

Test the connection and see the negotiated cipher:

openssl s_client -connect example.com:443

This shows the full handshake including the certificate chain, the negotiated protocol version, and the cipher suite. If the connection fails, the error message indicates why.

Test a specific TLS version:

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

If -tls1_2 fails but -tls1_3 succeeds (or vice versa), you know exactly which versions the server supports.

List all cipher suites the server accepts:

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

This lists every cipher suite the server will negotiate, organized by TLS version, along with a strength rating for each one.

What a properly configured server looks like#

A modern, properly configured web server should support:

• TLS versions: TLS 1.2 and TLS 1.3. Nothing older.
• Cipher suites: AEAD ciphers only (GCM or CHACHA20-POLY1305), with forward secrecy (ECDHE key exchange). No CBC, no RC4, no 3DES, no static RSA key exchange.
• Certificate: SHA-256 or higher signature, 2048-bit RSA or 256-bit ECDSA key, complete certificate chain.
• Session management: Session cache enabled, session tickets disabled (for perfect forward secrecy), reasonable session timeout.

A configuration that meets these requirements will work with every modern browser on every modern operating system without triggering version or cipher mismatch errors.

Summary#

ERR_SSL_VERSION_OR_CIPHER_MISMATCH means the browser and server cannot agree on how to encrypt the connection. The most common cause is a server still running TLS 1.0/1.1 or offering only deprecated cipher suites. Check the server’s configuration with SiteProbe’s SSL checker first – if it shows outdated TLS versions or weak ciphers, the server needs updating. If the server configuration looks correct, the problem is client-side: outdated OS, antivirus HTTPS inspection, stale browser cache, or QUIC interference. Unlike some SSL errors, this one has no bypass – the only fix is resolving the underlying incompatibility.