How to Fix ‘ERR_SSL_VERSION_OR_CIPHER_MISMATCH’ in Google Chrome

Encountering the error screen “This site can’t provide a secure connection” accompanied by the diagnostic code ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Google Chrome means the browser and the destination web server failed to establish an encrypted Transport Layer Security (TLS) handshake. Specifically, this error indicates that the client and server do not share a common SSL/TLS protocol version or cryptographic cipher suite. While this error frequently occurs on legacy websites relying on deprecated encryption standards (such as TLS 1.0 or RC4 ciphers), it is also regularly triggered by local SSL certificate state corruption, experimental QUIC protocol conflicts, or third-party antivirus HTTPS scanning interception. Resolving this issue involves flushing cached security certificates, toggling experimental network flags, and auditing browser security parameters.

Understanding Why TLS Handshake Negotiation Fails

During the initial phase of any HTTPS connection (the TLS Client Hello), Google Chrome sends the destination server an inventory of supported TLS protocol versions (TLS 1.2, TLS 1.3) and modern cipher suites (such as AES-GCM or ChaCha20-Poly1305). The server compares this list against its own cryptographic configurations. If the server only supports deprecated ciphers, or if an intermediate antivirus proxy modifies the handshake stream, Chrome terminates the connection to protect user confidentiality.

Common causes of ERR_SSL_VERSION_OR_CIPHER_MISMATCH include:

• Server Deprecation of Legacy TLS: Modern Chromium versions actively block connections to servers relying on TLS 1.0, TLS 1.1, or 3DES/RC4 encryption algorithms. For certificate validation issues, see our guide on fixing NET::ERR_CERT_DATE_INVALID in Google Chrome.
• Corrupted Windows SSL Certificate State: Stale intermediate certificate authority records cached in the Windows cryptographic store. For proxy routing errors, see our guide on fixing ERR_PROXY_CONNECTION_FAILED in Google Chrome.
• Third-Party Antivirus HTTPS Inspection: Antivirus software (such as Avast, Bitdefender, or Kaspersky) injecting a local root certificate that clashes with Chrome’s built-in root store. For socket aborts, check our guide on fixing ERR_CONNECTION_RESET in Chrome.
• Experimental QUIC Protocol Glitches: Instability in Chrome’s Quick UDP Internet Connections (QUIC) transport layer.

Handshake Phase	Negotiated Parameter	Mismatch Trigger
Client Hello	TLS Version (1.2 / 1.3)	Server only supports TLS 1.0 / 1.1
Cipher Selection	Cryptographic Algorithm	Server requires obsolete RC4 or MD5 hashing
Certificate Validation	Root CA Trust Chain	Antivirus HTTPS proxy alters cipher payload
UDP Transport (QUIC)	HTTP/3 Zero-RTT Handshake	Firewall drops UDP 443 packets mid-stream

Method 1: Clear the Windows SSL State

Windows maintains an operating system-wide SSL certificate cache. If a website’s cryptographic certificates were recently rotated, clearing the SSL state flushes obsolete certificates.

1. Press Win + R to open the Run dialogue.
2. Type inetcpl.cpl and press Enter to launch Internet Properties.
3. Navigate to the Content tab.
4. Under the Certificates section in the middle, click the button labelled Clear SSL state.
5. A confirmation prompt will state: “The SSL cache was successfully cleared.” Click OK.
6. Click OK to close Internet Properties, fully restart Google Chrome, and reload the target webpage.

Method 2: Disable Experimental QUIC Protocol

Google Chrome defaults to using QUIC (HTTP/3 over UDP) where supported. If network hardware or intermediate proxies drop or alter UDP TLS packets, disabling QUIC forces reliable TCP/TLS handshakes.

1. Open Google Chrome.
2. In the address bar, type chrome://flags and press Enter.
3. In the Search flags box at the top, type quic.
4. Locate the flag named Experimental QUIC protocol.
5. Click the drop-down menu on the right and select Disabled.
6. Click the blue Relaunch button at the bottom of the browser window to apply the change.

Method 3: Disable HTTPS / SSL Scanning in Antivirus Software

Many security suites inspect encrypted web traffic by deploying a local man-in-the-middle proxy. If the antivirus engine uses outdated cipher tables, Chrome detects this as an invalid handshake and blocks the page.

1. Open your installed antivirus or internet security control panel (e.g., Avast, AVG, Bitdefender, ESET).
2. Navigate to Settings > Core Shields > Web Shield (or Web Protection / Network Protection).
3. Locate settings referring to Enable HTTPS Scanning, Scan encrypted connections, or Check SSL certificates.
4. Temporarily toggle this option Off.
5. Refresh the affected website in Chrome. If the page loads immediately, update your antivirus software to the latest definition release or keep HTTPS inspection disabled.

Method 4: Flush DNS Cache and Reset Winsock Sockets

Stale DNS routing entries can point Chrome to decommissioned server IP addresses running legacy encryption stacks.

1. Press Win + S, type cmd, right-click Command Prompt, and select Run as administrator.
2. Flush the system DNS resolver cache:
   ipconfig /flushdns
3. Reset the Windows network socket stack:
   netsh winsock reset
4. Restart your computer to complete the network catalog refresh.

Method 5: Check Certificate Validity via Chrome Developer Tools

If the error persists and the destination site is an internal corporate tool, staging server, or unmaintained web property, inspect the server certificate directly to determine whether modern compliance standards are met.

1. Open Chrome, press Ctrl + Shift + I (or Cmd + Option + I on macOS) to open Developer Tools.
2. Select the Security tab from the top toolbar (click the >> arrows if hidden).
3. Review the Overview panel. It will explicitly display whether the connection is blocked due to “Obsolete Connection Settings” (such as TLS 1.0) or an “Insecure Cipher Suite”.
4. If the remote server only supports deprecated encryption, notify the server administrator to enable modern TLS 1.2 or TLS 1.3 protocols with forward secrecy ciphers.