How to fix ERR_SSL_PROTOCOL_ERROR
ERR_SSL_PROTOCOL_ERROR is Chrome telling you the TLS handshake failed before any certificate was validated. The browser and server could not agree on how to speak, so this is a server configuration or network problem, not a certificate-expiry problem. The goal is to find which layer broke.
- Likely cause
- Handshake failure: protocol, cipher, SNI, or a service not on 443
- Severity
- High — the connection never completes
- Time to fix
- About 15 minutes to isolate the failing layer
- Prevention
- Consistent TLS config and a config test before every reload
What causes it
- The server offers only protocol versions the browser has dropped, or the browser offers only versions the server has disabled, so the versions do not overlap.
- Nothing is actually listening with TLS on the port, or a plain-HTTP service was put on port 443 by mistake.
- A misconfigured virtual host or missing SNI makes the server answer with the wrong site or reset the connection.
How to fix it
1. Confirm TLS answers on the port at all
Open a raw TLS connection. A clean handshake prints the certificate; a reset or a hang points at the listener, not the certificate.
openssl s_client -connect example.com:443 -servername example.com </dev/null2. Test each protocol version
Force a specific version to see which the server accepts. If TLS 1.2 and 1.3 both fail, the server is offering only deprecated versions or none.
openssl s_client -connect example.com:443 -tls1_2 </dev/null openssl s_client -connect example.com:443 -tls1_3 </dev/null3. Fix the server TLS config and reload
Enable current protocols (TLS 1.2 and 1.3) in the web server, validate the config, then reload. Never reload an untested config on a live host.
sudo nginx -t sudo systemctl reload nginx
How to prevent it
Keep one known-good TLS configuration across servers, run the config test in your deploy pipeline, and grade the negotiated protocols from outside so a version drop is caught before visitors are.
Source: RFC 8446 (TLS 1.3 handshake)
Common questions
Is ERR_SSL_PROTOCOL_ERROR a certificate problem?
No. It happens before the certificate is validated, during the handshake. The cause is a protocol or cipher mismatch, a wrong listener, or an SNI/virtual-host misconfiguration.
It works in one browser but not another. Why?
Browsers support different protocol version ranges. A server offering only an old or only a very new protocol works in whichever browser still overlaps it and fails in the rest. Enable both TLS 1.2 and 1.3.
Fixed it? Catch the next one before your visitors do — monitor the certificate from outside, 3 free, no card.