The message ‘This site can’t provide a secure connection’ is Chrome’s umbrella error for any TLS handshake failure. It appears with different sub-codes depending on what actually went wrong, and the sub-code changes everything about the correct fix. Applying a generic fix list to this error is the same as treating every car warning light with the same repair procedure.
This guide is organized around signals: observable facts about your situation that narrow the cause before any fixing begins. Work through the signal questions in order. Each answer eliminates categories of causes and routes you to a specific section. You will not need to read the entire article.
Signal 1: Read the Sub-Code Chrome Shows
Below the main error message, Chrome shows a sub-code. If you do not see it, click the Details link or the Advanced button. The sub-code identifies the category of failure.
| Sub-code | What failed | Primary cause | Jump to section |
| ERR_SSL_PROTOCOL_ERROR | TLS handshake failed generically | HSTS conflict, wrong port, HTTP served on 443, antivirus, or flags | Section: ERR_SSL_PROTOCOL_ERROR Causes |
| ERR_SSL_VERSION_OR_CIPHER_MISMATCH | No shared TLS version or cipher | Server only supports deprecated TLS 1.0/1.1, or RC4/weak ciphers | Section: Version and Cipher Fixes |
| NET::ERR_CERT_DATE_INVALID | Certificate validity period mismatch | Server cert expired, or local clock is wrong | Section: Date and Clock Fixes |
| NET::ERR_CERT_AUTHORITY_INVALID | Certificate chain not trusted | Missing intermediate, self-signed cert, or outdated CA bundle | Section: Trust Chain Fixes |
| NET::ERR_CERT_COMMON_NAME_INVALID | Hostname not in certificate SANs | Wrong cert installed, missing www/non-www, uncovered subdomain | Section: Hostname Fixes |
| ERR_TOO_MANY_REDIRECTS | Redirect loop preventing HTTPS | HTTP to HTTPS redirect misconfigured with SSL not fully active | Section: Redirect Loop Fix |
If there is no sub-code visible, the error is likely ERR_SSL_PROTOCOL_ERROR. This is the least specific and most variable error Chrome produces. The signal questions below help narrow it down.
Signal 2: Scope of the Error
The second question to answer before touching anything: does the error appear on one specific site, or on many sites?
- Error on one specific site only: The problem is almost certainly in that server’s configuration or certificate. The visitor-side checks below are unlikely to help. Go directly to the server-side sections.
- Error on many or all HTTPS sites: The problem is on your device or network. Antivirus HTTPS scanning, a wrong system clock, a corrupted Chrome profile, or a corporate proxy are the likely causes. Go to the visitor-side sections.
- Error only on your corporate network, not at home: The corporate SSL inspection proxy is interfering. Contact IT. See the antivirus and proxy section.
- Error only in Chrome, not Firefox or Edge: Chrome-specific issue. HSTS cache, Chrome flags, or a Chrome profile problem. See the Chrome-specific section.
ERR_SSL_PROTOCOL_ERROR: The Causes and How to Separate Them
This sub-code fires for several unrelated reasons. The fastest path is eliminating causes systematically rather than trying fixes at random.
HSTS conflict: the most common cause for site owners
HTTP Strict Transport Security (HSTS) is a header that tells Chrome to only access a domain over HTTPS for a set period, cached by the browser. If a site previously sent an HSTS header and was later reconfigured without a valid HTTPS setup (such as during a staging rebuild or a domain change), Chrome refuses all HTTP connections to that domain and also rejects misconfigured HTTPS. This produces ERR_SSL_PROTOCOL_ERROR even when the server is reachable.
To check whether HSTS is the cause, type chrome://net-internals/#hsts in the Chrome address bar. Under Query HSTS/PKP domain, type the domain name and click Query. If the domain has a stored HSTS policy, it will show here. Under Delete domain security policies, type the domain name and click Delete, then retry the site.
HSTS cache clearing only affects your browser instance. Other visitors will still have the cached HSTS policy from previous visits. For site owners, the root fix is ensuring the HTTPS configuration is valid before the HSTS header is re-served. Clearing it from your browser is a testing tool, not a visitor fix.
HTTP accidentally served on port 443
A server that is sending plain HTTP traffic on port 443 (the HTTPS port) produces ERR_SSL_PROTOCOL_ERROR immediately, because Chrome expects to start a TLS handshake on port 443 and instead receives an HTTP response. This happens when an nginx or Apache configuration change removed the SSL context from the 443 listener and it fell back to serving plain HTTP, or when a site was migrated and port configuration was not updated.
Test this directly:
| # If openssl returns ‘wrong version number’, the server is sending HTTP on 443:
$ openssl s_client -connect yourdomain.com:443
# A correct TLS server responds with CONNECTED and then certificate data. # A server sending HTTP on 443 returns: # ‘wrong version number’ or ‘no peer certificate available’
# Also check if the site serves over HTTP correctly: $ curl -I http://yourdomain.com # If this returns 200 OK and your Nginx/Apache is missing ssl on the 443 block, # the 443 block is serving HTTP. Add ssl to the listen directive. |
Antivirus HTTPS scanning or corporate proxy
Antivirus products that intercept HTTPS connections can produce ERR_SSL_PROTOCOL_ERROR when their interception process fails mid-handshake. This is different from certificate errors where the antivirus successfully intercepts but presents an invalid certificate. Here, the interception attempt itself disrupts the handshake before Chrome can evaluate the certificate.
To confirm antivirus is the cause: open the same URL in an incognito window with extensions disabled. Incognito still passes through antivirus HTTPS scanning. If the error persists in incognito but disappears when you temporarily disable antivirus HTTPS scanning (Web Shield in Avast/AVG, Encrypted connections scanning in Kaspersky, HTTPS filtering in ESET, Encrypted Web Scan in Bitdefender), the antivirus interception is the source. Re-enable it after testing and add the affected site to the antivirus URL exclusions.
Corrupted Chrome SSL state or flags
After Chrome updates, flag changes, or SSL state corruption, ERR_SSL_PROTOCOL_ERROR can appear for sites that previously worked. Clear the SSL state (Win+R, inetcpl.cpl, Content tab, Clear SSL state) and clear Chrome’s internal sockets by visiting chrome://net-internals/#sockets and clicking Flush socket pools. Also check chrome://flags for any non-default SSL or network-related flags and click Reset all to restore defaults.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH: Server TLS Configuration
This sub-code means Chrome and the server have no TLS version or cipher suite in common. Chrome disabled TLS 1.0 and 1.1 in version 84 (August 2020). A server that only supports TLS 1.0 or 1.1 is now unreachable from any current browser. RC4, 3DES, export-grade ciphers, and other deprecated suites also produce this error.
This is always a server-side configuration issue. There is no client-side fix. The server administrator must enable TLS 1.2 and TLS 1.3 and configure a modern cipher suite list.
| # Check what TLS versions the server currently supports:
$ nmap –script ssl-enum-ciphers -p 443 yourdomain.com
# Or test specific versions: $ openssl s_client -connect yourdomain.com:443 -tls1_2 $ openssl s_client -connect yourdomain.com:443 -tls1_3
# Nginx fix: enable TLS 1.2 and 1.3 only # In nginx.conf or site config: ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; ssl_prefer_server_ciphers off;
# Apache fix: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE+AESGCM:ECDHE+CHACHA20:!aNULL:!eNULL:!EXPORT:!RC4:!3DES
# After changes, reload and verify via SSL Labs: # https://www.ssllabs.com/ssltest/ |
NET::ERR_CERT_DATE_INVALID: Certificate Expiry or Clock Mismatch
Two causes produce this sub-code. Read the expiry date Chrome shows in the error details (click Advanced). If the date is in the past and your clock shows today’s correct date, the server’s certificate is expired and must be renewed. If the date shown is far in the future or before the current date, your device clock is wrong.
Wrong system clock
Windows: right-click the taskbar clock, select Adjust date and time, enable Set time automatically. Mac: System Settings, General, Date and Time, enable Set time and date automatically. After correcting, restart Chrome and reload.
Expired server certificate
Only the server owner can fix this. Renew the certificate and redeploy it. After renewal, verify the new certificate is being served by checking the expiry date in the browser or via openssl s_client.
NET::ERR_CERT_AUTHORITY_INVALID: Trust Chain Problems
The browser cannot verify the certificate’s chain of trust. Three scenarios cause this.
Missing intermediate certificate
The server is sending only its leaf certificate without the intermediate CA certificate that connects it to a trusted root. This is the most common scenario. Test it: run openssl s_client -connect yourdomain.com:443 -showcerts and count the certificates. If only one appears, the intermediate is missing. The fix is downloading the intermediate from your CA and concatenating it into the certificate bundle served by your web server.
Self-signed certificate
The certificate was not issued by any CA. For public-facing sites, replace it with a certificate from a publicly trusted CA. Let’s Encrypt issues free DV certificates. For development environments, use mkcert to generate a locally trusted certificate rather than a raw self-signed one.
Corporate proxy presenting its own certificate
If the Issuer field in the certificate viewer shows a corporate or security vendor name rather than a public CA (DigiCert, Sectigo, Let’s Encrypt), a network appliance is intercepting the connection. This is expected on managed corporate devices where IT has installed the corporate CA in the system trust store. If the corporate CA was not installed on your device, all HTTPS connections through the proxy fail validation. Contact IT for the corporate root CA certificate and installation instructions.
NET::ERR_CERT_COMMON_NAME_INVALID: Hostname Not in Certificate
The hostname you are visiting does not appear in the certificate’s Subject Alternative Names. Common causes: visiting www.yourdomain.com when the certificate only covers yourdomain.com (or vice versa), a subdomain not included in the certificate, or a CDN presenting a certificate for a different domain.
| # Verify what hostnames the certificate covers:
$ openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -text | grep -A5 ‘Subject Alternative Name’
# If the visited hostname is not in the SAN list, # the certificate must be reissued to include it. # Reissue with both yourdomain.com and www.yourdomain.com as SANs. # Or use a wildcard: *.yourdomain.com covers all single-level subdomains. |
ERR_TOO_MANY_REDIRECTS: The HTTPS Redirect That Loops
This error appears when the HTTP to HTTPS redirect is configured but the HTTPS side is not fully working, creating a loop where Chrome follows the redirect but HTTPS fails, falls back, and hits the redirect again. The most common scenario on WordPress: SSL is not yet active or the certificate is not installed, but the site’s wp-config.php or .htaccess already forces HTTPS.
| # Check what redirection headers the server returns on HTTP:
$ curl -IL http://yourdomain.com
# If you see a 301 redirect to https:// followed by the SSL error, # the redirect is working but HTTPS itself is broken. # The fix depends on the cause of the underlying HTTPS failure.
# For WordPress: temporarily comment out the HTTPS force in wp-config.php: # define(‘FORCE_SSL_ADMIN’, true);Â <– comment this out # Then fix the certificate issue, then re-enable.
# Check .htaccess for redirect rules: # Remove or disable RewriteRule.*https until the SSL cert is working. |
Visitor-Side Checklist: When the Problem Is on Your Device
If the error affects multiple sites and you have confirmed other people can reach the affected sites without problems, work through these in order.
- Check and correct your system clock. An incorrect date breaks certificate validation across all HTTPS sites simultaneously. This is the highest-yield single check.
- Open the site in incognito mode with all extensions disabled. If it loads in incognito, an extension is the cause. Re-enable extensions one at a time to identify the offending one.
- Try a different browser. If the error appears in Chrome but not Firefox, the issue is Chrome-specific: profile corruption, flags, or cached SSL state.
- Clear the Chrome SSL state. Press Win+R, type inetcpl.cpl, go to Content tab, click Clear SSL state. Then clear Chrome’s socket pool via chrome://net-internals/#sockets, Flush socket pools.
- Reset Chrome flags to default. Navigate to chrome://flags and click Reset all. Relaunch Chrome.
- Disable antivirus HTTPS scanning temporarily. If the error clears, the antivirus interception is the source. Re-enable it and add the affected site to the antivirus URL exclusions list rather than leaving scanning off.
- Try a different network (mobile hotspot). If the error disappears, the issue is your home router, ISP, or corporate network proxy.
- Update Chrome to the latest version. An outdated Chrome version may lack support for TLS configurations the server requires.
Server-Side Checklist: When You Own the Site Showing the Error
Run your domain through the SSL Labs test at ssllabs.com/ssltest first. It identifies most server-side certificate and TLS configuration problems in one pass and explains exactly what is wrong.
| Check | Verify with | Fix if failing |
| Certificate not expired | openssl s_client: check notAfter date | Renew immediately; enable automated renewal |
| Full chain sent | openssl s_client -showcerts: count is 2 or 3 | Concatenate intermediate to certificate file; reload server |
| Certificate covers visited hostname | Check SAN list in cert viewer or openssl output | Reissue with correct SANs including www and non-www variants |
| TLS 1.2 and 1.3 enabled | SSL Labs Protocol Support section | Update ssl_protocols (Nginx) or SSLProtocol (Apache) |
| No weak ciphers | SSL Labs Cipher Suites section | Remove RC4, 3DES, export, and non-AEAD suites from config |
| HTTP redirects to HTTPS | curl -I http://yourdomain.com returns 301 | Add HTTP to HTTPS redirect in server config |
| New cert actually being served | openssl s_client from external host | Reload web server; purge CDN cache; verify config points to new file |
| SSL Labs overall grade | Run ssllabs.com/ssltest | Address each flagged issue in the report |
Frequently Asked Questions
What does ‘this site can’t provide a secure connection’ mean?
It means Chrome could not complete the TLS handshake required to establish an HTTPS connection. The TLS handshake can fail for several reasons: the server’s certificate is expired or untrusted, the certificate does not cover the domain being visited, the server only supports deprecated TLS versions Chrome no longer accepts, the TLS negotiation was disrupted by antivirus or a proxy, or the HTTPS setup is partially broken on the server. The specific error code Chrome shows alongside this message (ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH, etc.) identifies which of these applies.
Why does this error appear only in Chrome and not in Firefox?
Chrome and Firefox have different TLS policies and different trust store implementations. Chrome follows stricter HSTS enforcement and has its own HSTS preload list. Chrome removed TLS 1.0 and 1.1 support earlier than some other browsers. Chrome uses a separate SSL state cache that Firefox does not share. If the error appears only in Chrome, the most likely causes are a cached HSTS policy in Chrome that conflicts with the current site configuration, Chrome-specific flags or profile data, or a Chrome extension that modifies network behavior. Clear the Chrome HSTS cache for the domain via chrome://net-internals/#hsts and test whether the error clears.
The error appears on my own site after I installed an SSL certificate. Why?
Several post-installation issues produce this. The web server may not have been reloaded after the certificate files were written, so it is still serving the old (possibly expired or absent) certificate. The certificate bundle may be missing the intermediate certificate, causing chain validation failure. The ssl_certificate directive in Nginx or SSLCertificateFile in Apache may point to the wrong file path. HTTP requests may already be redirecting to HTTPS before the HTTPS configuration is complete, creating a redirect loop. Verify the configuration with openssl s_client and run the SSL Labs test to identify exactly what is wrong.
Can clearing browser cache fix this error?
Clearing the regular browser cache (cookies, cached images) rarely fixes SSL errors. What sometimes helps is clearing the SSL state (separate from the browser cache, accessed via inetcpl.cpl on Windows) and flushing the socket pool in Chrome (via chrome://net-internals/#sockets). These remove cached TLS session data rather than cached web content. For errors caused by a stale HSTS policy, clearing the HSTS cache via chrome://net-internals/#hsts is the specific action that helps.
Is it safe to bypass this error?
It depends on which specific error is causing it. For ERR_SSL_PROTOCOL_ERROR with no sub-code visible, and if you are testing your own development server, bypassing may be acceptable while you fix the configuration. For NET::ERR_CERT_REVOKED, never bypass. For errors on sites where you enter credentials or payment information, do not bypass. The error exists because Chrome cannot verify the connection is secure. Proceeding means you are accepting the risk that the connection could be intercepted or that you are not communicating with the intended server.
