ERR_SSL_PROTOCOL_ERROR: What It Means and How to Fix It

Chrome and Edge show ERR_SSL_PROTOCOL_ERROR under the heading "This site can't provide a secure connection" with the line "sent an invalid response." It means the browser began a TLS handshake and got back something that was not valid TLS, or the handshake broke off halfway. Unlike a certificate warning, there is no "Proceed anyway" link, because no certificate was ever evaluated.

Firefox reports the same family of failures as "Secure Connection Failed" with codes such as SSL_ERROR_RX_RECORD_TOO_LONG or SSL_ERROR_PROTOCOL_VERSION_ALERT. Safari says "Safari can't establish a secure connection to the server."

If you are a visitor

Work through these in order and stop when the page loads.

1. Check the date and time on your device. A clock that is wrong by more than a day can break the handshake. Turn on automatic time sync.
2. Try another network. Switch from Wi-Fi to a phone hotspot. If it works, your router, ISP or a captive portal is interfering.
3. Pause HTTPS scanning in antivirus or a security suite. Products that inspect encrypted traffic sometimes send malformed handshakes. Disable "HTTPS scanning" or "web shield" temporarily to test.
4. Clear the SSL state. On Windows, open Internet Options, Content tab, and choose Clear SSL state. In Chrome, clear cached images and cookies for the site.
5. Disable QUIC as a test. Open chrome://flags/#enable-quic, set it to Disabled, and relaunch. If this fixes it, a firewall is mishandling UDP 443 traffic.
6. Test in an incognito window with extensions off. Extensions that rewrite requests (VPN, privacy tools) can cause the error.
7. Try another browser. If Firefox loads the site and Chrome does not, the cause is local to Chrome's profile or flags.

If a different device on the same network also fails, the problem is probably the site. Check with our website health check before spending more time.

If you own the site

The error nearly always comes from a server that does not speak TLS on the port the browser is using, or that offers nothing the browser accepts.

1. TLS is not enabled on port 443

The most common cause is a virtual host listening on 443 without TLS turned on, so it answers a handshake with plain HTTP. In nginx:

# Wrong: port 443 speaks plain HTTP
server {
    listen 443;
    server_name example.com;
}

# Right
server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
}

In Apache, confirm SSLEngine on is inside the <VirtualHost *:443> block and that mod_ssl is loaded (apachectl -M | grep ssl).

You can see this from the outside. If curl -v https://example.com/ prints "error:0A00010B:SSL routines::wrong version number" (OpenSSL 3) or "unknown protocol," the server is not doing TLS on that port.

2. The reverse proxy or load balancer talks plain HTTP to a TLS port

If your proxy forwards HTTPS traffic to a backend that expects HTTP (or the reverse), the handshake fails. Verify the backend scheme in your proxy config, for example proxy_pass http://127.0.0.1:8080; versus https://.

3. The server only offers protocols browsers refuse

Servers limited to SSLv3 or TLS 1.0/1.1 fail with different wording in modern Chrome, usually ERR_SSL_VERSION_OR_CIPHER_MISMATCH, but some stacks surface this protocol error instead. Allow at least TLS 1.2 and ideally 1.3:

ssl_protocols TLSv1.2 TLSv1.3;

4. SNI or default-host problems

When several sites share an IP, the server picks the certificate using the SNI name the browser sends. If the default vhost has no valid ssl_certificate, or a stale config references a missing file, some clients get a broken handshake. Run nginx -t or apachectl configtest, then check the error log for lines mentioning SSL_CTX_use_PrivateKey or "no shared cipher."

5. CDN or firewall in the middle

If you use a CDN, confirm its TLS mode is compatible with your origin. A firewall doing deep inspection or a stuck load balancer node can also corrupt handshakes; test the origin IP directly:

openssl s_client -connect ORIGIN_IP:443 -servername example.com </dev/null

A healthy result prints a certificate chain and Verification details. An immediate "wrong version number" or "unexpected eof" confirms the origin.

Confirm the fix

1. Run the SSL Checker against the hostname. It should return a certificate and chain rather than a connection failure.
2. Use the TLS वर्शन चेकर to confirm TLS 1.2 or 1.3 is offered.
3. Use the पोर्ट चेकर to verify port 443 is open from outside your network.
4. Add an uptime monitor on the HTTPS URL so the next handshake failure alerts you.

अगले कदम

• Read the full SSL/TLS certificate errors guide for how the handshake works.
• If the handshake succeeds but the browser distrusts it, see ERR_CERT_AUTHORITY_INVALID.
• If the protocols do not overlap, see ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
• Debug an incomplete chain with the SSL Chain Debugger.

सामान्य प्रश्न

Is ERR_SSL_PROTOCOL_ERROR a certificate problem?

Usually not. It happens before or during the handshake, so the cause is typically protocol, port or proxy configuration rather than the certificate itself. Expiry and name errors have their own messages.

Why does it work in Firefox but not in Chrome?

Chrome may be using QUIC, a flag, an extension or a local security product that Firefox is not. Test in incognito and with QUIC disabled to find which.

Can I bypass it?

No. Chrome gives no override because there is no certificate to accept. The server or the network between you and it has to be fixed.

Does my antivirus really cause this?

It can. Software that intercepts HTTPS replaces the server's certificate with its own, and bugs or outdated versions can produce invalid handshakes. Turning off HTTPS scanning briefly is a quick test.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.