What's happening
You type a URL, the browser spins for a second, then bails with:
This site can't provide a secure connection. ERR_SSL_PROTOCOL_ERROR
The browser attempted a TLS handshake and it fell apart. Possible culprits: a bad cipher suite, a protocol version mismatch, a misconfigured server, or something local (proxy, firewall, antivirus) cutting into the connection.
Note what this error isn't. ERR_CERT_INVALID means a certificate problem. ERR_CONNECTION_REFUSED means the server is down. With ERR_SSL_PROTOCOL_ERROR, the server is reachable — the handshake itself is what's broken.
Debug process
Step 1: Rule out your browser first
Open the same URL in a different browser and in a private/incognito window. Works in one but not the other? The problem is browser-local — think extensions, cached data, or settings. Fails everywhere? The issue is on the server or somewhere in your network path.
Step 2: Probe the server directly
Skip the browser entirely and use openssl to talk to the server raw:
# Basic TLS handshake test
openssl s_client -connect example.com:443
# Test specific TLS versions
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3
# Enumerate supported cipher suites
nmap --script ssl-enum-ciphers -p 443 example.com
If openssl s_client also chokes on the handshake, the browser isn't the problem. You're looking at the server or the network.
Step 3: Check if HTTPS is being intercepted
Corporate firewalls and antivirus products — Kaspersky, Avast, Bitdefender — commonly do SSL inspection. They terminate your TLS connection and re-encrypt it with their own certificate. When that injected cert isn't trusted, or when the interception breaks TLS 1.3 negotiation, you get ERR_SSL_PROTOCOL_ERROR.
# Linux/macOS: see who actually issued the certificate you're receiving
openssl s_client -connect example.com:443 | openssl x509 -noout -issuer -subject
If the issuer shows your antivirus vendor or an internal company CA instead of something like Let's Encrypt or DigiCert, traffic is being intercepted.
Solutions
Fix 1: Clear SSL state and browser cache
Stale SSL session data can poison new handshake attempts. Clear it out.
Chrome:
1. Go to chrome://settings/privacy → Clear browsing data
2. Check "Cached images and files" and "Cookies"
3. Then go to chrome://net-internals/#hsts → delete the domain entry if one exists
Windows (system-level SSL cache):
certutil -URLCache * delete
macOS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Fix 2: Turn off SSL scanning in your antivirus
This is the fix that works most often in home and corporate environments. Here's where to find the setting in the three most common offenders:
Kaspersky: Settings → Network → Encrypted connections scanning → select Do not scan encrypted connections (or add the site as an exception).
Avast: Menu → Settings → Protection → Core Shields → Web Shield → uncheck Enable HTTPS scanning.
Bitdefender: Protection → Online Threat Prevention → toggle off Encrypted Web Scan.
Reload the page immediately after. If it loads, you've found your culprit.
Fix 3: Force a TLS version in Chrome (testing only)
If the server only supports older TLS and your browser has dropped it, this gets you in temporarily:
# Launch Chrome allowing TLS 1.0+ (do not use in production)
chrome --ssl-version-min=tls1
Since Chrome 84 (released July 2020), TLS 1.0 and 1.1 are disabled by default. You can also check chrome://flags and search "TLS" to see what's toggled. That said — if you control the server, upgrade its TLS config instead. Downgrading the browser is a short-term diagnostic, not a fix.
Fix 4: Fix server-side TLS config (if you control the server)
nginx:
server {
listen 443 ssl;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
ssl_certificate /etc/ssl/certs/your_cert.pem;
ssl_certificate_key /etc/ssl/private/your_key.pem;
}
sudo nginx -t && sudo systemctl reload nginx
Apache:
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite HIGH:!aNULL:!MD5
SSLHonorCipherOrder on
sudo apache2ctl configtest && sudo systemctl reload apache2
Fix 5: Sync your system clock
TLS certificates carry strict validity windows. A system clock that's off by even 10–15 minutes can silently kill handshakes. Check it first — it's a quick win that's easy to miss.
# Linux
timedatectl status
sudo timedatectl set-ntp true
# macOS
sudo sntp -sS time.apple.com
# Windows (run as Administrator)
w32tm /resync /force
Fix 6: Flush DNS and reset the network stack
# Windows (run as Administrator — restart after)
ipconfig /flushdns
netsh winsock reset
netsh int ip reset
# Linux
sudo systemd-resolve --flush-caches
# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
Verify the fix worked
# Confirm TLS handshake completes
curl -v https://example.com 2>&1 | grep -E '(SSL|TLS|cipher|certificate)'
# Check which TLS version was negotiated
curl -v --tlsv1.2 https://example.com 2>&1 | grep 'SSL connection'
# Expected output:
# * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
curl succeeds and shows a TLS version? The handshake is working. Open the URL in your browser — a padlock in the address bar confirms you're done.
Key takeaways
- Antivirus SSL scanning is the most common cause in home and office environments. If the error appeared out of nowhere and nothing changed on the server, start here.
- TLS 1.0 and 1.1 are gone. Servers still advertising only these versions will be rejected by every modern browser. TLS 1.2 is the minimum; TLS 1.3 is what you want.
- A wrong system clock breaks HTTPS silently. TLS validation is time-sensitive by design. It's one of the first things to check and the last thing most people think of.
openssl s_clientis your best diagnostic tool — it bypasses browser policies and shows exactly what the server is offering.