What's the difference between this and ERR_SSL_PROTOCOL_ERROR?

They share the same Chrome headline — "This site can't provide a secure connection" — but the code beneath it tells you which problem you have. ERR_SSL_PROTOCOL_ERROR is the generic signal that the TLS handshake broke for any of several reasons: HTTPS not served at all, a missing or invalid certificate, an interfering proxy, or corrupted local SSL state. ERR_SSL_VERSION_OR_CIPHER_MISMATCH is much narrower: it means the browser and server share no common TLS version or cipher suite, so they literally cannot agree on how to encrypt the connection. In practice the protocol error sends you on a broad investigation, while the version-or-cipher mismatch points straight at the server's enabled protocols and ciphers. If you see the mismatch code, start by widening the accepted TLS versions and ciphers rather than chasing certificate issues.

Why does it happen on my own site?

On a site you control, this almost always means the server's TLS configuration and a modern browser have no settings in common. The most frequent cause is a server still pinned to obsolete protocol versions (TLS 1.0 or 1.1) or legacy ciphers (such as RC4 or 3DES) that current versions of Chrome have removed support for — so negotiation fails before any page loads. Other causes are an incomplete certificate chain, where the server omits the intermediate certificate, or a listener on port 443 that isn't actually serving TLS, perhaps because a plain-HTTP backend or a misrouted reverse proxy is exposed there. Enable TLS 1.2 and 1.3 with a current cipher suite, deploy the full certificate chain, and confirm that port 443 genuinely terminates TLS. After each change, reload the service and re-test from a fresh browser session.

Is it my computer or the website?

Either side can cause this error, so it's worth a quick test to find out. The fastest way is to open the same URL on a different device and network — for example your phone on mobile data instead of your home Wi-Fi. If the site loads cleanly elsewhere, the problem is local to your original machine: an outdated browser or operating system, a wrong system clock, corrupted SSL cache, or antivirus software that intercepts HTTPS traffic. If the site fails on every device and network you try, the issue is on the server, and only the site's owner can fix it by correcting the TLS configuration or certificate. A second clue is breadth: if many sites fail at once, suspect your computer or your security software; if only one site fails everywhere, suspect that server.

How do I fix it on nginx or Apache?

On both servers the fix is the same idea: offer modern protocol versions and ciphers, and serve the complete certificate chain. On nginx, set ssl_protocols to TLSv1.2 TLSv1.3, provide a current ssl_ciphers list, and point ssl_certificate at a full-chain file that includes the intermediates, then reload with nginx -s reload. On Apache, set SSLProtocol to -all +TLSv1.2 +TLSv1.3 in the SSL virtual host, set SSLCipherSuite to a modern list, supply SSLCertificateChainFile, and reload with apachectl graceful. After reloading, verify the live result with openssl s_client -connect example.com:443 -servername example.com, which should report the negotiated TLS version and cipher and show the full certificate chain. If openssl errors out or hangs, the listener on 443 isn't serving TLS correctly and that is the next thing to fix.

Fix "This Site Can't Provide a Secure Connection" in Chrome

When Chrome refuses to load a page, it usually does so with a blunt, full-width headline: This site can't provide a secure connection. It is one of the most common things people see when an HTTPS site goes wrong, and it is also one of the most misunderstood — partly because Chrome shows it for several distinct underlying problems.

This guide explains what the headline means, what visitors can try, and what site owners should check, with a particular focus on the cipher-and-version mismatch case that produces ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

What does this error mean?

The headline is Chrome's human-readable summary of a failed TLS handshake. Before any page content is exchanged, your browser and the server negotiate an encrypted channel: they agree on a TLS protocol version, pick a cipher suite, and the server presents its certificate.

If any step of that negotiation cannot complete, Chrome abandons the connection and shows this screen instead of the website. Below the headline you will almost always find a short error code that tells you which step failed. The cipher suites a modern browser will accept are catalogued in RFC 8446, Appendix B.4.

The two codes that pair with this headline most often are ERR_SSL_PROTOCOL_ERROR and ERR_SSL_VERSION_OR_CIPHER_MISMATCH. The first is a generic "the secure handshake broke" signal that can stem from a wide range of causes — a missing certificate, HTTPS not being served at all, an interfering proxy, or a corrupted local SSL state. We cover that one in depth in our companion article.

The second is far more specific: it means the browser and the server share no common ground on which TLS version or cipher suite to use. That distinction matters, because it points the diagnosis in a clear direction rather than leaving you guessing.

It helps to know which side of the connection is at fault. The error is generated locally by your browser, but the underlying cause can live on your machine (out-of-date software, a wrong clock, security tooling that intercepts HTTPS) or on the server (TLS misconfigured, certificate chain incomplete, or no TLS on port 443 at all). The fixes below are organised around exactly that split.

If you're just visiting

If you hit this on a site you do not control — your bank, a shop, a news site — the problem is often on your end, and there are a handful of quick checks worth running before you assume the website is broken.

Update your browser and operating system

Modern servers increasingly require TLS 1.2 or TLS 1.3 and decline the obsolete TLS 1.0 and 1.1 versions. A very old browser or operating system may simply not support a protocol version or cipher the server insists on, which produces a version-or-cipher mismatch on your side. Update Chrome to the latest release and apply pending operating system updates, then reload the page.

Fix your computer's clock

TLS certificates are only valid within a fixed window of dates. If your system clock is wrong — often after a dead CMOS battery or a reset — the certificate can appear expired or not-yet-valid, and the handshake fails. Set the date, time and time zone to update automatically, then revisit the site.

Clear the SSL state and stale data

Browsers cache certificate and connection information, and a stale or corrupted entry can cause repeated failures even after the underlying issue is gone. Clearing cached images and files, and on Windows clearing the SSL state, often resolves a connection that broke once and then refused to recover.

Check antivirus or security software that scans HTTPS

Many antivirus suites and corporate security tools inspect encrypted traffic by sitting in the middle of your HTTPS connections. When that interception is misconfigured or relies on outdated TLS support, it can break the handshake and surface this exact error. Temporarily disable the "HTTPS scanning", "SSL scanning" or "encrypted connection scanning" feature and try again; if that fixes it, update or reconfigure the tool rather than leaving protection off.

If you own the site

If visitors report this headline on your own site, the handshake is failing at the server. Work through the configuration from the protocol layer outward.

Enable TLS 1.2 and TLS 1.3 with a modern cipher suite

The single most common cause of ERR_SSL_VERSION_OR_CIPHER_MISMATCH is a server that only offers protocol versions or ciphers that modern browsers no longer accept. Chrome has removed support for TLS 1.0/1.1 and for legacy ciphers such as the old RC4 and 3DES suites.

If your server is pinned to those, current browsers have nothing in common with it and the negotiation fails immediately. Configure the server to offer TLS 1.2 and TLS 1.3 alongside a current, widely recommended set of cipher suites.

On nginx, that looks like this:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/ssl/certs/example.com.fullchain.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
}

On Apache, the equivalent directives in the SSL virtual host are:

<VirtualHost *:443>
    ServerName example.com

    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile   /etc/ssl/private/example.com.key
    SSLCertificateChainFile /etc/ssl/certs/example.com.chain.crt

    SSLProtocol             -all +TLSv1.2 +TLSv1.3
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384
    SSLHonorCipherOrder     off
</VirtualHost>

Reload the service after editing — nginx -s reload or apachectl graceful — and test the configuration before assuming it took effect.

Make sure port 443 actually serves TLS

A subtler version of this failure happens when something is listening on port 443 but not speaking TLS — for example a plain-HTTP backend exposed on the wrong port, or a reverse proxy terminating on the wrong listener. The browser tries to start a handshake and gets unencrypted bytes back, which it cannot interpret as TLS. Confirm the TLS service is bound to 443 and responds correctly with a quick check:

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

A healthy response shows the negotiated protocol and cipher and the presented certificate chain. If it errors out or hangs, the listener is not serving TLS the way you expect.

Finish the certificate chain

Even with the right protocols and ciphers, an incomplete chain — where the server sends its leaf certificate but omits the intermediate certificate — can break the connection for clients that cannot fill the gap. Always deploy the full chain (leaf plus intermediates), which is what the fullchain and chain files in the examples above provide.

Not sure which TLS versions and ciphers your server offers?

Check your SSL configuration →

What's the common gotcha?

ERR_SSL_VERSION_OR_CIPHER_MISMATCH means something very specific: there is no overlap between the TLS versions and cipher suites the browser supports and the ones the server offers. This is different from a generic protocol error. A classic trigger is a server that was deliberately pinned to a single old cipher to keep a legacy client (an old payment terminal, an embedded device, a decade-old internal app) working — and that one cipher is now rejected by every modern browser. Widening the server's accepted versions and ciphers to include current ones, rather than narrowing them, is what restores the overlap. If you must keep an old client alive, serve it from a separate listener so you don't cripple everyone else.

Where to go next

Once the handshake completes, the rest of the certificate and HTTPS picture is worth understanding too. For the broader map of every common secure-connection failure, see our pillar guide on SSL/TLS errors. And because this headline so frequently shares a screen with the generic protocol code, the companion article on ERR_SSL_PROTOCOL_ERROR walks through the wider set of causes behind that specific code.

How to Fix "This Site Can't Provide a Secure Connection"