ERR_SSL_PROTOCOL_ERROR: How to Fix "Sent an Invalid Response"

ERR_SSL_PROTOCOL_ERROR is Chromium net error -107, described in the source as “An SSL protocol error occurred.” It is a catch-all: when BoringSSL, Chrome's TLS library, aborts a handshake for a reason that has no dedicated Chrome code, Chrome's error mapping falls back to ERR_SSL_PROTOCOL_ERROR. The error page reads “This site can't provide a secure connection” followed by “host sent an invalid response.”

The failure sits at the TLS layer. DNS resolved and the TCP connection opened, but the bytes that came back were not a TLS handshake Chrome could accept. It is not a certificate problem (those are ERR_CERT_* codes on a “Your connection is not private” page), not a wrong system clock (that gives ERR_CERT_DATE_INVALID), and usually not a version or cipher disagreement: Chrome maps “no common TLS version or cipher” to ERR_SSL_VERSION_OR_CIPHER_MISMATCH. A server that only speaks TLS 1.0 or 1.1 therefore produces the mismatch error, not this one.

The triggers that actually produce this code, roughly from most to least common:

• Plain HTTP where TLS is expected. An nginx listen 443; without ssl, a Docker mapping like 443:80, a load balancer forwarding 443 to an HTTP backend, or https:// typed for a dev server that only speaks HTTP. The server answers the ClientHello with an HTTP 400 page, which cannot be parsed as a TLS record.
• HSTS forcing https onto an HTTP-only port. HSTS covers every port of a host. Once a domain, or a preloaded TLD such as .dev or .app, has HSTS, http://host:8080 is rewritten to https://host:8080; if that port speaks HTTP, you get this error.
• Renegotiation Chrome refuses. Chrome accepts a server-initiated TLS 1.2 renegotiation only on HTTP/1.1 connections. A server that asks for a client certificate mid-connection over HTTP/2, or under TLS 1.3, which has no renegotiation at all, gets the connection aborted.
• Broken TLS interception. Antivirus HTTPS scanning, corporate inspection proxies and some VPN clients terminate TLS themselves; a buggy one sends malformed handshake messages.
• Non-compliant TLS stacks on embedded devices, old appliances or custom code that send malformed or out-of-order handshake messages.

Two things that look related but are not: HTTP/3 failures run over QUIC and carry their own codes such as ERR_QUIC_PROTOCOL_ERROR, so disabling QUIC does not fix this error. And middleboxes that choke on the larger post-quantum ClientHello Chrome has sent since version 124 typically cause dropped or reset connections (ERR_CONNECTION_RESET), not this code.

The browser's TLS session ends at the first TLS terminator, so this error is about that hop. Origin TLS failures behind Cloudflare appear as Cloudflare 525 or 526 pages, not as ERR_SSL_PROTOCOL_ERROR.

nginx

server {
    listen 443 ssl;          # without "ssl" this port answers in plain HTTP
    listen [::]:443 ssl;     # the IPv6 line needs "ssl" too
    http2 on;                # nginx 1.25.1+; older: listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
}

A classic partial outage: listen 443 ssl; is correct but listen [::]:443; lacks ssl. Visitors who reach the site over IPv4 are fine; everyone with working IPv6 gets ERR_SSL_PROTOCOL_ERROR.

Cloudflare

With the DNS record proxied (orange cloud), Cloudflare terminates TLS at its edge, so a misconfigured origin port cannot produce this code in the browser. It can appear when the record is DNS only (grey cloud) or Cloudflare is paused: browsers then connect straight to your origin, which must serve real TLS on 443 itself.

HAProxy and load balancers

A TCP-mode frontend on 443 that forwards to an HTTP backend produces the plain-HTTP symptom exactly. Either terminate TLS on the frontend (bind :443 ssl crt /etc/haproxy/certs/example.pem) or make sure the backend itself speaks TLS.

1. See what the port really returns.

   curl -sv https://example.com/ -o /dev/null
   # "wrong version number" in the TLS error = the port answered in plain HTTP
   curl -si http://example.com:443/ | head -1
   # an HTTP status line here confirms it

2. Run a handshake by hand, with SNI: openssl s_client -connect example.com:443 -servername example.com -brief </dev/null. A healthy server prints the protocol version and cipher; garbage or an immediate error points at the listener. Repeat against the IPv6 address with -connect '[2001:db8::10]:443'.
3. Fix the listener: add ssl to every listen on 443, then nginx -t && systemctl reload nginx. In Docker, docker ps must not show 0.0.0.0:443->80/tcp unless the container terminates TLS on 80.
4. Request client certificates at handshake time, not per path. Mid-connection client-certificate requests rely on renegotiation, which Chrome refuses on HTTP/2 and TLS 1.3.
5. Still unclear? Capture a NetLog. Open chrome://net-export, reproduce the error, stop logging and look for the SSL_HANDSHAKE_ERROR event: it records the underlying BoringSSL error reason that ERR_SSL_PROTOCOL_ERROR hides.

• Isolate the browser: try an incognito window (extensions off) and a second browser. If only one Chrome profile fails, an extension or a proxy setting is involved.
• Isolate the network: switch to mobile data. If the site works there, something on the original network is intercepting TLS: a corporate proxy, router, VPN or filtering DNS.
• Antivirus HTTPS scanning: temporarily turn off the web or HTTPS scanning feature and retry; if that fixes it, update the product or exclude the site.
• Restart the browser fully. This drops pooled sockets and cached TLS sessions; chrome://net-internals/#sockets offers “Flush socket pools” for the same effect.
• Local dev hosts only: if localhost or your own test domain is being forced to https, delete its entry at chrome://net-internals/#hsts.

Clearing the cache and cookies does not help: certificates and handshakes are not stored in the HTTP cache. A wrong system clock is not the cause either. If the error appears on every network, device and browser, the fault is on the server and only the site owner can fix it.

openssl s_client -connect example.com:443 -servername example.com -brief </dev/null
# CONNECTION ESTABLISHED
# Protocol version: TLSv1.3
curl -sI https://example.com/ | head -1
# HTTP/2 200

Run both over IPv4 and IPv6 (curl -4, curl -6) if the site has an AAAA record. To check the handshake, protocol versions and certificate from outside your network, run the domain through the SSL/TLS checker.

• ERR_SSL_VERSION_OR_CIPHER_MISMATCH — no common TLS version or cipher
• SSL_ERROR_RX_RECORD_TOO_LONG — Firefox's name for plain HTTP on 443
• SSL handshake failed — the general handshake failure
• ERR_CERT_DATE_INVALID — what a wrong clock or expired certificate really shows