ERR_SSL_PROTOCOL_ERROR

ERR_SSL_PROTOCOL_ERROR means the browser and the server could not agree on how to set up the encrypted (HTTPS) connection. The connection itself was made, but the TLS negotiation that secures it failed, so no page could be loaded safely. Chrome, Edge, Brave and Opera display the exact string ERR_SSL_PROTOCOL_ERROR when the handshake breaks.

What it means

Before any HTTPS data is exchanged, browser and server run a TLS handshake. The client says which protocol versions and ciphers it supports; the server picks a match, presents its certificate, and both sides derive session keys. ERR_SSL_PROTOCOL_ERROR fires when that negotiation cannot complete — for example, when the client sends a TLS ClientHello and the server answers with something that is not valid TLS at all.

This is a protocol failure, which separates it from certificate trust errors. Messages such as ERR_CERT_AUTHORITY_INVALID or SSL_ERROR_BAD_CERT_DOMAIN mean the handshake worked but the certificate was not trusted. Here the handshake never got that far. The most common real-world trigger is a scheme mismatch: you point https:// at a server that only speaks plain HTTP on that port, or http:// at a port expecting TLS. The server's reply is ordinary plaintext, the browser expects a TLS record, and the negotiation collapses immediately.

When it affects every site rather than one, the cause usually sits on your machine: a proxy or antivirus filter rewriting traffic, a wrong system clock, or a browser that has had modern TLS disabled.

Common causes

• The URL uses the wrong scheme or port — https:// on a plain-HTTP server, or http:// on a TLS port.
• The server's certificate or TLS configuration is broken, expired, or set to a version the browser rejects.
• The server or browser still relies on an outdated TLS version that the other side has disabled.
• A proxy, VPN, or antivirus “HTTPS scan” feature is intercepting and corrupting the handshake.
• The system clock is badly wrong, so certificate validity checks cannot be evaluated correctly.

How to fix it

1. Check the address and scheme. Type the domain with https:// and again with http://. If only one works, the site expects that scheme. Remove any port that looks wrong, such as :8080 or :8443, and try the standard 443.
2. Fix the system clock. Right-click the clock and sync the time, or open Settings → Time & language → Date & time and enable automatic time. Certificate checks fail when the clock is off by days or years.
3. Test without middleboxes. Disconnect the VPN, disable the proxy, and turn off your antivirus's HTTPS/SSL scanning. Then retry, and re-enable each one in turn to see which breaks the handshake.
4. Update the browser and clear its secure state. Install the latest version so modern TLS is enabled. In Chromium browsers you can clear the SSL cache and HSTS state at chrome://net-internals/#hsts, and clear browsing data to drop stale secure cookies.
5. If you manage the server, inspect the TLS setup. A misconfigured certificate chain or a protocol list the client no longer accepts produces this error for every visitor. Test the host with an online SSL checker and confirm that the certificate chain is complete and TLS 1.2 or newer is offered.

How to prevent it

On your own machine, keep the browser, operating system and time zone up to date, and be careful with tools that promise to inspect encrypted traffic. Anything that sits between the browser and the server — a proxy, a VPN, a scanning antivirus — can break TLS, so run as few of them as you can and note which ones you enable.

If you run the site, treat TLS as a managed service rather than a one-time setup. Renew certificates automatically, keep the chain complete, disable retired protocol versions on purpose rather than by accident, and monitor the endpoint so a broken handshake is caught before users hit it. A short expiry reminder and a certificate check in your deployment pipeline prevent the most common server-side causes.