ERR_SSL_VERSION_OR_CIPHER_MISMATCH: Causes and How to Fix It

ERR_SSL_VERSION_OR_CIPHER_MISMATCH is Chromium net error -113: “The client and server don't support a common SSL protocol version or cipher suite.” Chrome shows “This site can't provide a secure connection” and “host uses an unsupported protocol.” The handshake fails at its very first exchange, before any certificate is validated.

Chrome raises it when the server picks a TLS version Chrome no longer accepts, when no cipher suite overlaps, when the server answers with a protocol_version or insufficient_security alert, and when the server rejects the ClientHello itself with a handshake_failure alert. That last case is how most servers and CDNs respond when they have no certificate at all for the requested hostname, so the name of the error is misleading: on a modern stack, a missing certificate is the most common cause. It is not a certificate-name mismatch (that is ERR_CERT_COMMON_NAME_INVALID) and not an expired or SHA-1 certificate (those are other ERR_CERT_* codes).

• No certificate for this hostname. Cloudflare's documentation names this as the usual cause on its network: the edge certificate is not active yet, a custom certificate expired, or the hostname is a multi-level subdomain such as a.b.example.com that Universal SSL does not cover.
• Server limited to TLS 1.0 or 1.1. Chrome removed both in version 84 (2020); Chromium's own error list notes that TLS 1.0/1.1 now cause this error. Typical on old appliances, NAS boxes, printers and unpatched Windows Server builds with TLS 1.2 disabled.
• Only obsolete cipher suites. RC4 and export suites are long gone, and Chrome's cipher string explicitly excludes 3DES and the CBC-mode ECDSA suites with an SHA-1 MAC. A server whose list contains only such suites shares nothing with Chrome.
• Certificate and cipher list do not fit, for example an ECDSA certificate with only RSA cipher suites enabled.
• TLS interception by antivirus or a corporate proxy with an outdated TLS library, which fails toward the browser.

When a CDN or load balancer terminates TLS, the browser only negotiates with it, so its certificate coverage and TLS settings are what matter.

Cloudflare

• Open SSL/TLS > Edge Certificates and confirm a certificate is Active and lists the exact hostname. Proxied DNS records that no certificate covers are flagged “This hostname is not covered by a certificate”.
• Second-level subdomains (a.b.example.com) need an advanced or custom certificate.
• If you need the site up immediately while a certificate activates, Cloudflare's documented workaround is to pause Cloudflare temporarily.
• Check Minimum TLS Version on the same page; a high minimum shuts out clients that cannot reach it.

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

Since nginx 1.23.4 the default ssl_protocols already includes TLSv1.2 and TLSv1.3, so on a current nginx the usual culprit is an inherited, hand-written list. Apache equivalent: SSLProtocol -all +TLSv1.2 +TLSv1.3. Note that TLS 1.3 suites are configured separately from ssl_ciphers and are always available when TLS 1.3 is on.

1. Test each version with SNI:

   openssl s_client -connect example.com:443 -servername example.com -tls1_2 -brief </dev/null
   openssl s_client -connect example.com:443 -servername example.com -tls1_3 -brief </dev/null
   # "alert protocol version"  -> that version is disabled
   # "alert handshake failure" -> no cert for this name or no shared cipher

2. List what the server accepts: nmap --script ssl-enum-ciphers -p 443 example.com or testssl.sh example.com. You need at least one ECDHE suite with AES-GCM or ChaCha20 under TLS 1.2, plus TLS 1.3.
3. Check the name is covered: repeat the handshake with each hostname you serve (apex, www, deeper subdomains). If one name fails and another works on the same IP, the server has no certificate for it.
4. Apply the config above, then nginx -t && systemctl reload nginx. On hardware you cannot upgrade, put a reverse proxy with a current TLS stack in front of it.
5. On Windows Server, confirm TLS 1.2 is enabled for SChannel and that IIS has a binding with a certificate for this hostname.

• Update the browser and the OS; an old build may lack cipher suites the server now requires.
• Turn off antivirus HTTPS or web scanning briefly and retry; if that fixes it, update the product.
• Try mobile data. Success there means a proxy or filter on your usual network is negotiating TLS for you.
• Do not re-enable TLS 1.0 or old ciphers in the browser: Chrome has no switch for it, and it would only make the connection weaker.

Clearing cache, cookies or SSL state does not help. If every browser on every network fails, the server or CDN configuration is the cause.

openssl s_client -connect example.com:443 -servername example.com -brief </dev/null
# Protocol version: TLSv1.3
# Ciphersuite: TLS_AES_128_GCM_SHA256
curl -sv --tlsv1.2 --tls-max 1.2 https://example.com/ -o /dev/null

Repeat for every hostname and for IPv6 if you publish AAAA records. The SSL/TLS checker shows the negotiated protocol, cipher and certificate from outside your network.

• ERR_SSL_PROTOCOL_ERROR — the handshake reply was not valid TLS
• SSL_ERROR_PROTOCOL_VERSION_ALERT — Firefox, server refused the TLS version
• SSL_ERROR_NO_CYPHER_OVERLAP — Firefox, no shared cipher
• ERR_CERT_COMMON_NAME_INVALID — a certificate was sent, but for another name
• Weak cipher suites explained