{"id":4283,"date":"2026-11-09T12:18:00","date_gmt":"2026-11-09T12:18:00","guid":{"rendered":"https:\/\/www.ucartz.com\/blog\/this-site-cant-provide-a-secure-connection\/"},"modified":"2026-11-09T22:05:32","modified_gmt":"2026-11-09T22:05:32","slug":"this-site-cant-provide-a-secure-connection","status":"publish","type":"post","link":"https:\/\/www.ucartz.com\/blog\/this-site-cant-provide-a-secure-connection\/","title":{"rendered":"This Site Can’t Provide a Secure Connection: Causes and Fixes"},"content":{"rendered":"\n

“This site can’t provide a secure connection” is the error page Google Chrome (and Chromium, the open-source browser it is built on) shows when the HTTPS (TLS) handshake with a website fails before any page is sent. The error code underneath tells you why. ERR_SSL_PROTOCOL_ERROR<\/code> usually means the server answered with something that is not valid TLS, often plain HTTP on the HTTPS port. ERR_SSL_VERSION_OR_CIPHER_MISMATCH<\/code> means the server only offers old TLS versions or ciphers the browser no longer accepts. In most cases the fix is on the server, so visitors can do little except check their own network. Site owners can usually fix it in a few minutes.<\/p>\n\n\n\n

\"Terminal
An expired certificate stops the connection; a healthy site shows its certificate name and end date<\/figcaption><\/figure>\n\n\n\n

Read the error code first<\/h2>\n\n\n\n

The heading is the same for several different faults. We checked Chromium’s own source code (localized_error.cc<\/a> and its error page strings) to see which errors produce it and what line appears below the heading:<\/p>\n\n\n\n

Error code<\/th>Line under the heading<\/th>Usual cause<\/th><\/tr><\/thead>
ERR_SSL_PROTOCOL_ERROR<\/code><\/td>“site<\/em> sent an invalid response.”<\/td>The server did not answer with valid TLS, for example plain HTTP on port 443, or something in between broke the connection<\/td><\/tr>
ERR_SSL_VERSION_OR_CIPHER_MISMATCH<\/code><\/td>“site<\/em> uses an unsupported protocol.” plus “The client and server don’t support a common SSL protocol version or cipher suite.”<\/td>The server only allows TLS 1.0 or 1.1, or only old ciphers<\/td><\/tr>
ERR_SSL_OBSOLETE_CIPHER<\/code><\/td>“site<\/em> uses an unsupported protocol.”<\/td>The server’s cipher is too old<\/td><\/tr>
ERR_SSL_SERVER_CERT_BAD_FORMAT<\/code><\/td>“site<\/em> doesn’t adhere to security standards.”<\/td>A malformed certificate<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Certificate problems are a different error page. An expired, self-signed or wrong-name certificate gives “Your connection is not private” with a code starting NET::ERR_CERT_<\/code>. If that is what you see, our guide to SSL certificates that are not trusted<\/a> is the right place.<\/p>\n\n\n\n

What we saw in a test<\/h2>\n\n\n\n

We set up small Nginx 1.31.6 test servers in Docker and opened each one in Chromium 154, then checked them with curl 8.22.0:<\/p>\n\n\n\n

Server set-up<\/th>Chromium<\/th>curl<\/th><\/tr><\/thead>
Plain HTTP on port 443 (listen 443;<\/code> without ssl<\/code>)<\/td>ERR_SSL_PROTOCOL_ERROR<\/code><\/td>(35) ... wrong version number<\/code><\/td><\/tr>
TLS 1.0 and 1.1 only<\/td>ERR_SSL_VERSION_OR_CIPHER_MISMATCH<\/code><\/td>(35) ... tlsv1 alert protocol version<\/code><\/td><\/tr>
Self-signed certificate for another name<\/td>ERR_CERT_AUTHORITY_INVALID<\/code> (the “not private” page)<\/td>(60) SSL: no alternative certificate subject name matches target hostname<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The first two produce “This site can’t provide a secure connection”; the third does not. The plain-HTTP server was working fine: curl http:\/\/plain.test:443\/<\/code> returned its page. It was simply speaking the wrong protocol on the HTTPS port.<\/p>\n\n\n\n

If you are visiting the site<\/h2>\n\n\n\n
    \n
  1. Check the address.<\/strong> A typo, or an address with a port such as https:\/\/example.com:80<\/code>, sends HTTPS to a port that does not speak it.<\/li>\n\n\n\n
  2. Reload once.<\/strong> A server that was restarting may answer normally a moment later.<\/li>\n\n\n\n
  3. Try another network,<\/strong> such as mobile data instead of office Wi-Fi. If the site works there, something on the first network, like a firewall, proxy or filter that inspects HTTPS, is interfering.<\/li>\n\n\n\n
  4. Turn off HTTPS scanning in your antivirus<\/strong> or security software for a quick test, if it has such a feature. These products sit between the browser and the site and can break the handshake.<\/li>\n\n\n\n
  5. Try another device.<\/strong> If the site fails everywhere for everyone, only the site owner can fix it. Let them know, and include the error code.<\/li>\n<\/ol>\n\n\n\n

    Do not look for a browser setting that re-enables old TLS versions. RFC 8996<\/a> formally deprecated TLS 1.0 and 1.1 because they lack current cryptographic algorithms, and the site needs to be updated instead.<\/p>\n\n\n\n

    If it is your website<\/h2>\n\n\n\n

    1. Reproduce it from a terminal<\/h3>\n\n\n\n
    curl -sS -o \/dev\/null https:\/\/example.com\/\nopenssl s_client -connect example.com:443 -servername example.com <\/dev\/null<\/code><\/pre>\n\n\n\n
    The messages map straight to the browser codes: wrong version number<\/code> means the port is not speaking TLS, and alert protocol version<\/code> means no common TLS version. Add -servername<\/code> with the site name so the right virtual host answers, as it would for a browser. Our article on SSL handshake failures<\/a> goes through more of these messages.<\/p>\n\n\n\n
    2. Make sure port 443 really speaks HTTPS<\/h3>\n\n\n\n
    This is the classic cause of ERR_SSL_PROTOCOL_ERROR<\/code>: a virtual host listens on 443 but TLS is not switched on for it.<\/p>\n\n\n\n