ERR_SSL_PROTOCOL_ERROR

What this error means & how to recognize it

• Chrome or Edge reports “This site can’t provide a secure connection” with ERR_SSL_PROTOCOL_ERROR.
• The failure may affect the entire site, one subdomain, or only one hostname behind a proxy or load balancer.
• Plain HTTP on port 80 may work while HTTPS fails, indicating a problem in the TLS path rather than necessarily in the application.
• The error may start after a certificate renewal, server migration, web-server configuration change, CDN change, or change to the service listening on port 443.
• A direct origin test and a public hostname test may produce different results when a CDN, reverse proxy, or load balancer is involved.

Root causes, ordered by likelihood

1. Port 443 is serving plain HTTP or another non-TLS protocol. The HTTPS listener may be missing, or the wrong service may have bound to port 443. The browser then receives data that is not a TLS handshake.
2. The HTTPS virtual host or server block is incorrect. The server may listen on the wrong address, select the wrong hostname, or lack the TLS directives required by the web server.
3. A CDN, reverse proxy, or load balancer has an origin mismatch. The proxy may be using HTTP while the origin expects HTTPS, or it may connect to the wrong port or backend.
4. The TLS configuration is incompatible or malformed. Unsupported protocol versions, restrictive cipher settings, SNI routing problems, or a misconfigured TLS-terminating device can stop the handshake before certificate validation.
5. The certificate or chain is unusable. An expired certificate, missing intermediate certificate, or certificate that does not cover the requested hostname can prevent a secure connection. Some browsers and connection paths show a more specific certificate warning instead.
6. A renewed certificate was not loaded by the service. Updating certificate files on disk does not change the certificate presented by a running web server until its configuration is reloaded or restarted according to the service’s documented procedure.

How to fix it

1. Establish whether the failure is public, origin-specific, or local

Try the exact failing hostname from a second network or device. If only one computer fails, check local security software, interception proxies, and system time. If every client fails, continue with the server, proxy, CDN, or load-balancer investigation.

If HTTP works but HTTPS does not, focus on the TLS listener, port 443, certificate selection, and any proxy between the client and origin. Do not assume that an HTTP success proves the HTTPS configuration is correct.

2. Test the TLS handshake without changing server state

From an administrative terminal with network access to the endpoint, run:

openssl s_client -connect [your-hostname]:443 -servername [your-hostname] -showcerts

The -servername option matters when SNI selects certificates or virtual hosts. Record whether the handshake starts, which certificate is returned, the certificate expiry, the Subject Alternative Name hostnames, and whether intermediate certificates are included.

• If the connection returns plain HTTP or fails before any certificate appears, inspect the port 443 listener and proxy routing.
• If a certificate is returned, compare it with the requested hostname and check its validity dates and chain.
• If a direct origin test works but the public hostname fails, inspect the CDN, reverse proxy, load balancer, or DNS path rather than changing the application.

3. Verify the HTTPS listener and hostname routing

With appropriate server access and authorization, inspect the active web-server configuration and confirm that:

• the intended service is listening on port 443;
• the HTTPS server block or virtual host is enabled;
• the requested hostname is included in the relevant server_name or ServerName/ServerAlias settings;
• TLS is enabled for that listener; and
• the certificate and private-key paths point to the intended files.

For Nginx, check the enabled server block and its listen 443 ssl configuration. For Apache, check the <VirtualHost *:443> configuration and SSLEngine on. Do not copy directives between products without checking the syntax and version supported by the installed server.

4. Validate the certificate and chain

Confirm that the presented certificate:

• is not expired or prematurely invalid;
• covers the exact hostname in its Subject Alternative Name entries;
• matches the corresponding private key; and
• is accompanied by the required intermediate certificate chain.

A certificate for the bare domain does not automatically cover every subdomain. The subdomain must be listed explicitly or covered by an appropriate wildcard certificate. If the server presents only the leaf certificate, install the chain file supplied by the certificate authority in the format required by the web server.

5. Check renewal and certificate loading

For a Certbot-managed deployment, an administrator can run certbot renew --dry-run to test the renewal workflow without issuing a production certificate. Review the output, renewal configuration, permissions, and the service’s reload hook.

If renewal succeeded but clients still receive the old certificate, confirm that the web server or TLS-terminating proxy has loaded the new files. A reload or restart changes service state and should be performed only during an approved maintenance window, with a rollback plan and the product’s documented procedure. Keep this operational action separate from read-only diagnostics.

6. Inspect CDN, proxy, and load-balancer TLS settings

Identify where TLS terminates: at the CDN, edge proxy, load balancer, or origin server. Verify that the configured origin protocol and port match what the origin actually serves.

If a CDN offers modes such as Flexible, Full, or Full (strict), select the mode that matches the origin’s real configuration and certificate validity. A less strict mode may hide the underlying problem or create a different failure; it is not a durable substitute for a valid origin certificate. Make configuration changes only with authorization, then retest both the public hostname and the origin path where possible.

7. Check for protocol, SNI, or network-device interference

If the endpoint presents a valid matching certificate but the handshake still fails, compare results from different networks and TLS clients. Review firewall, load-balancer, web-application-firewall, and TLS-inspection settings for blocked protocol versions, unsupported cipher policies, incorrect SNI routing, or altered traffic. Preserve the handshake output and relevant server logs for the hosting provider or network administrator.

Prevention & how to verify the fix

• Monitor certificate expiry independently of the renewal mechanism and alert before certificates become invalid.
• Test renewal in a non-production or dry-run workflow and verify that the service reload hook actually presents the new certificate.
• Keep a documented inventory of every hostname, TLS termination point, certificate, private key, and intermediate chain.
• After changes to certificates, proxies, load balancers, or port mappings, test the public hostname and each important subdomain.
• Review TLS configuration changes for SNI, protocol-version, cipher, and origin-port compatibility before deployment.
• Retain recent server, proxy, and certificate details so a failed handshake can be compared with the last known-good configuration.

Frequently asked questions