Why does the site work on my phone but not my computer?

That pattern almost always means the problem is local to your computer or its network: a wrong system clock, an antivirus HTTPS-scanning feature, a corporate proxy, or cached SSL state. Start with the clock and an incognito window before suspecting the server.

Is ERR_SSL_PROTOCOL_ERROR the same as this error?

Yes. ERR_SSL_PROTOCOL_ERROR is the technical code Chrome shows alongside the 'can't provide a secure connection' message. Both mean the TLS handshake failed before any page content loaded, a transport problem, not a page error.

Can an expired certificate cause this exact message?

It can, though an expired cert more often produces a NET::ERR_CERT_DATE_INVALID warning. Either way, checking the certificate's validity dates with an SSL checker or openssl is the fastest way to confirm or rule it out.

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

VigilDog Team · October 6, 2026 · 6 min read

"This site can't provide a secure connection" is Chrome's blunt way of saying the TLS handshake failed before a single byte of your page loaded. The frustrating part is that the message is identical whether the problem is your laptop clock, a corporate proxy, or a genuinely broken certificate on the server. This guide walks the causes in the order worth checking, so you fix the real one instead of clearing cache for the tenth time.

What the error actually means

Before a browser shows you any content over HTTPS, it negotiates an encrypted channel with the server: agree on a TLS version, pick a cipher, verify the certificate, exchange keys. "This site can't provide a secure connection" (usually paired with ERR_SSL_PROTOCOL_ERROR) means that negotiation broke down. Nothing about your page rendered yet, this is a transport-layer failure, not an application error.

That distinction matters because it splits the causes cleanly into two buckets: something on your machine or network is interfering with the handshake, or the server is offering something the browser refuses to accept. Work through your side first, it's faster to rule out and it's the more common culprit for a site that works for everyone else.

Fix it on your side first

If the site loads fine on your phone over cellular but fails on your laptop, the problem is almost certainly local. Run through these before touching anything server-side:

Check your system clock. TLS validates certificate dates against your local time. A clock that's days off will reject a perfectly valid cert. Set date and time to automatic and retry.
Try an incognito window and a different browser. This isolates extensions, a poisoned cache, and stale HSTS state in one move.
Clear the SSL state / cached certificates. On Windows: Internet Options > Content > Clear SSL State. In Chrome, clearing 'Cached images and files' also helps.
Temporarily disable antivirus or 'HTTPS scanning' features. Security suites like Avast, Kaspersky, and ESET intercept TLS to inspect it and frequently break handshakes with modern servers.
Disable QUIC in chrome://flags. Some networks mishandle HTTP/3 over UDP, and Chrome's fallback isn't always clean.
Switch networks. Captive portals, aggressive corporate proxies, and some public Wi-Fi rewrite or block TLS. If cellular works and office Wi-Fi doesn't, that's your answer.

When the problem is the server

If the site fails for multiple people on different networks, the server is offering a TLS configuration the browser won't accept. The most common cause today is a protocol mismatch: modern browsers have dropped TLS 1.0 and 1.1, so a server that only speaks those old versions gets a hard refusal. The same happens when a server advertises only weak, deprecated cipher suites.

A second frequent cause is an incomplete certificate chain. Your server sends its own certificate, but to trust it the browser has to build an unbroken path up to a root CA it already trusts. If the server forgets to send the intermediate certificate, some clients (notably those without cached intermediates) can't complete that path and abort the handshake, which surfaces as this exact error even though the certificate itself is valid.

The TLS certificate chain of trust

Diagnose the certificate and chain

Don't guess at chain problems, inspect them. From a terminal, openssl s_client -connect example.com:443 -servername example.com prints every certificate the server presents and reports 'Verify return code'. If you see only the leaf certificate and no intermediate, the chain is incomplete and you need to install the CA bundle your issuer provides. The -tls1_2 and -tls1_3 flags let you confirm which protocol versions actually negotiate.

For a faster read, run the domain through our SSL checker, it flags an expired cert, a missing intermediate, a hostname mismatch, and unsupported protocol versions without you decoding OpenSSL output. If the certificate has simply lapsed, our guide to fixing an expired SSL certificate covers renewal and reinstallation step by step.

One subtlety worth naming: a hostname mismatch (the certificate is for www.example.com but you visited example.com, or vice versa) produces a related but distinct warning. If your error names the certificate's subject, you're looking at a coverage gap in the cert's SAN list, not a handshake protocol failure.

Stop learning about it from a browser tab

Every server-side cause here, an expired certificate, a dropped intermediate after a renewal, a TLS version quietly deprecated by a hosting change, is silent until a visitor hits the error. By then the damage is done: search crawlers see a broken site and real users bounce, assuming they were about to be phished.

That's exactly the gap continuous SSL and certificate monitoring closes. VigilDog watches the full chain, expiry dates, and the negotiated protocol from the outside, the same way a browser sees them, and alerts you weeks before a cert lapses or the moment a chain breaks after a deploy. For agencies, the white-label reports mean you can prove every client site is healthy without logging into ten dashboards.