ERR_SSL_PROTOCOL_ERROR: site can't provide a secure connection

ERR_SSL_PROTOCOL_ERROR means the TLS handshake failed because Chrome received a response it could not use as TLS. The certificate was never checked. On a single site, the server is usually misconfigured; on many sites, something on your computer or network is interfering with HTTPS.

Is it the site or your device?

One failing site points to the server; many failing sites point to your device or network. Run a check from outside your network with the SSL checker:

curl ssl.sh/example.com

• The checker also cannot complete a handshake: the server is broken. Visitors cannot fix this; tell the site owner.
• The checker succeeds: the problem is local. Try the same page on mobile data instead of Wi-Fi, in an incognito window (extensions disabled), and with antivirus HTTPS scanning paused. Whichever change fixes it identifies the cause.

Causes

1. Port 443 speaks plain HTTP

The most common server mistake: a listen 443; without ssl, or an application listening on 443 without TLS. Chrome sends a ClientHello and receives an HTTP response. Confirm:

curl -sv http://example.com:443/ -o /dev/null 2>&1 | head -5

If that returns an HTTP response, add TLS to the listener. Firefox reports the same problem as SSL_ERROR_RX_RECORD_TOO_LONG.

2. Broken or incomplete TLS configuration

A missing certificate file, a private key that does not match, or a TLS terminator that crashes mid-handshake can all end with garbage or a reset. Check the server's error log and test with:

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

3. Proxy, firewall or antivirus interference

Security software that inspects HTTPS, outdated corporate proxies and some home routers rewrite or cut TLS traffic. If disabling HTTPS scanning or switching networks fixes it, see antivirus HTTPS scanning and corporate SSL inspection.

4. HSTS forcing HTTPS on an HTTP-only host

If a domain once sent a Strict-Transport-Security header, Chrome upgrades every request to HTTPS. A development or legacy host that only serves HTTP then fails with this error. Serve HTTPS properly, or for your own dev hostnames see HSTS errors.

5. Wrong system date or an outdated browser

Rarely, an old browser cannot negotiate with a modern server. Update the browser and confirm the date is correct.

What it looks like in each browser

How site owners fix it

A port 443 listener with TLS enabled and a modern protocol set fixes nearly every server-side case.

1. Make sure the listener speaks TLS. In Nginx:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name example.com;
    ssl_certificate     /etc/nginx/ssl/example.com.fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
}

The http2 on; directive needs Nginx 1.25.1 or later; on older versions use listen 443 ssl http2;.

2. Validate and reload. Run nginx -t and fix any errors before systemctl reload nginx.

3. Use a modern protocol set. Enable TLS 1.2 and 1.3 only; the TLS config generator produces a tested block for Nginx, Apache and others.

4. Re-test from outside. curl ssl.sh/example.com should show a completed handshake, the negotiated protocol and the certificate chain. If it works from the checker but not from a specific client network, the issue is on that network.