ERR_SSL_PROTOCOL_ERROR — Server Side or Your Side?

Where a TLS Handshake Can Break

The handshake is a short conversation with several places to go wrong. Knowing them makes the error much less mysterious.

The browser opens by listing the TLS versions and ciphers it supports. The server picks one it also supports — and if there is no overlap, the conversation ends there. The server then presents its certificate, which the browser validates for expiry, hostname match and a trusted issuing chain. Any of those checks failing ends it too. Finally both sides derive session keys; a clock that is badly wrong on either machine can break even this stage.

Because all of this happens before any HTTP request is sent, the server never sees a request for a page. That is why nothing appears in your access log, and why the error looks identical no matter which URL you tried.

Causes on the Server Side

• The certificate has expired. The most common cause by a distance, and usually the result of auto-renewal failing quietly weeks earlier.
• The certificate does not match the hostname. A certificate for example.com will not cover www.example.com unless both names are listed on it.
• An incomplete certificate chain. The server sends its own certificate but omits the intermediate, so browsers cannot build a path to a trusted root. Notoriously, this often works in one browser and fails in another.
• Only obsolete TLS versions are enabled. Modern browsers have removed TLS 1.0 and 1.1 entirely, so a server offering only those has nothing left to agree on.
• No overlapping cipher suite. A hardened configuration can be so restrictive that older clients cannot connect at all.
• The wrong certificate is being served — common on servers hosting several sites where the default virtual host answers for a name it does not have a certificate for.
• Port 443 is open but nothing is listening properly on it, or a proxy in front is terminating TLS incorrectly.

Causes on Your Side

• Your device clock is wrong. Certificates are valid between two dates; if your clock says last year, every certificate looks invalid. This is a classic on machines whose battery has died.
• Antivirus or security software intercepting HTTPS. Many suites man-in-the-middle your traffic to scan it, and their interception frequently breaks handshakes.
• A corporate proxy or firewall doing TLS inspection without its root certificate properly installed.
• An outdated browser or operating system that no longer shares any modern protocol with the server.
• A stale local SSL state. Browsers cache handshake information and a bad entry can persist after the server side has been fixed.
• A VPN interfering with the connection, especially ones that filter or rewrite traffic.

Which Side Is It? A One-Minute Test

Run these three checks before changing anything. Together they tell you which half of this article applies.

Fixes, in Order

• Check your device clock first. It takes five seconds and it is a genuinely common cause. Turn on automatic time sync.
• Try a private window and another browser. If one browser works, the problem is local state or an extension.
• Disable antivirus HTTPS scanning temporarily and reload. If that fixes it, add the site to the exclusion list rather than leaving protection off.
• Clear the browser SSL state. Chrome exposes this under privacy settings; clearing cached images and files usually clears it too.
• If it fails on mobile data as well, stop looking at your device — run an SSL checker against the domain and read what it says.
• On the server, renew the certificate if it has expired, and then find out why auto-renewal did not run. A certificate that expired once will expire again.
• Install the full chain, not just the certificate. Most providers supply a fullchain file specifically for this — using the wrong file is the usual cause of "works in Chrome, fails in Safari".
• Enable TLS 1.2 and 1.3 on the server and disable the older versions. Both are required in practice: 1.3 for modern clients, 1.2 for everything slightly older.
• Confirm the certificate covers every hostname people actually use, including the www variant.

Preventing a Repeat

• Automate certificate renewal, then monitor that the automation ran. Unmonitored automation is how certificates expire.
• Set an expiry alert at 14 days, independent of the renewal system, so a silent failure still reaches you.
• Use a certificate covering both the bare domain and the www subdomain, or a wildcard if you have several subdomains.
• Test with an external SSL checker after any certificate or server change, rather than trusting that your own browser loads it.
• Keep TLS configuration current. A configuration written five years ago may allow protocols that browsers have since removed entirely.