How to Fix “This Site Can’t Provide a Secure Connection” Error

The "This site can't provide a secure connection" error means your browser failed to complete a TLS handshake with the target server. The connection attempt was terminated before any encrypted channel could be established, leaving the browser unable to verify the server's identity or negotiate a cipher suite.

This error surfaces across Chrome, Firefox, Edge, and Safari and is almost always accompanied by a specific error code — most commonly ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH, or SSL_ERROR_HANDSHAKE_FAILURE_ALERT. Each code points to a distinct failure layer: the server's certificate configuration, the client's TLS stack, or the network path between them. Identifying which layer is responsible before touching any settings will save you significant time.

What Actually Happens During a TLS Handshake

Before diving into fixes, understanding the failure mechanism matters. When your browser connects to an HTTPS site, it performs a TLS handshake in milliseconds:

1. The browser sends a ClientHello message advertising supported TLS versions and cipher suites.
2. The server responds with a ServerHello, selecting a protocol version and cipher, then presenting its certificate chain.
3. The browser validates the certificate against trusted root Certificate Authorities (CAs), checks the expiry date, verifies the domain matches the Subject Alternative Name (SAN), and confirms the certificate has not been revoked (via OCSP or CRL).
4. Both sides derive session keys and begin encrypted communication.

A failure at any of these four steps produces the "can't provide a secure connection" message. The error code in the browser's detail pane tells you exactly which step broke.

Root Causes Mapped to Error Codes

If the error code places responsibility on the server administrator and you do not control the server, your options are limited to contacting the site owner. The remaining sections focus on errors you can resolve on the client side, followed by server-side remediation for administrators.

Client-Side Fixes

1. Verify the Certificate Before Changing Anything

Click the padlock (or the warning icon) in the address bar and select Connection is secure > Certificate is valid. Check:

• Validity period: The "Not After" date must be in the future.
• Issued to: The domain in the certificate's SAN field must match the URL exactly, including subdomains.
• Issued by: The CA chain must terminate at a root CA your OS trusts.

If the certificate is expired or mismatched and you do not own the server, stop here and contact the site owner. If you manage the server, jump to the server-side section below.

2. Synchronize System Date and Time

Certificate validation is time-sensitive. A system clock that is even a few minutes off can cause the browser to conclude a valid certificate is expired, or that a not-yet-valid certificate is being used prematurely.

Windows:

w32tm /resync /force

Alternatively, right-click the system clock, select Adjust date/time, and enable Set time automatically with the Windows Time service.

Linux (systemd):

timedatectl set-ntp true
timedatectl status

macOS: Open System Settings > General > Date & Time and enable Set time and date automatically.

After syncing, restart the browser and retest.

3. Clear the Browser's SSL State and Cache

Browsers cache certificate validation results and HSTS (HTTP Strict Transport Security) policies. A stale cache entry can block access even after a server-side certificate issue has been resolved.

Chrome — clear browsing data:

Navigate to chrome://settings/clearBrowserData, select All time, check Cookies and other site data and Cached images and files, then click Clear data.

Chrome — clear HSTS entry for a specific domain:

Navigate to chrome://net-internals/#hsts, enter the domain under Delete domain security policies, and click Delete. This is particularly useful when a domain was previously HTTPS-only and is now misconfigured.

Windows — clear the OS-level SSL state:

Control Panel > Network and Internet > Internet Options > Content tab > Clear SSL State

This clears the certificate cache used by Internet Explorer, Edge (legacy), and some Windows applications.

Firefox: Navigate to about:preferences#privacy, scroll to Cookies and Site Data, and click Clear Data.

4. Disable Antivirus HTTPS Inspection

Security products from vendors including Avast, AVG, Kaspersky, ESET, and Bitdefender perform SSL/TLS interception — they act as a local man-in-the-middle proxy, re-signing certificates with their own root CA. When their root CA is not properly installed in the browser's trust store, or when the interception module is buggy, every HTTPS connection fails.

To test whether this is the cause:

1. Temporarily disable the Web Shield, HTTPS Scanning, or SSL Filtering feature in your antivirus settings.
2. Reload the failing page.
3. If the error disappears, the antivirus is the culprit.

The permanent fix is to add the affected domain to the antivirus's exclusion list rather than disabling HTTPS scanning globally, which would reduce your security posture.

5. Update the Browser

Modern TLS requires browser support for TLS 1.2 at minimum, and TLS 1.3 for optimal security. Browsers older than approximately Chrome 70, Firefox 63, or Edge 79 may lack TLS 1.3 support or have known handshake bugs.

Chrome:

Navigate to chrome://settings/help. Chrome checks for updates automatically and installs them on restart.

Firefox:

Navigate to about:support, then Check for Updates under the Help menu.

Keeping the browser current also ensures the browser's built-in root CA store is up to date, which matters for certificates issued by newer CAs.

6. Audit TLS Protocol Settings in the Browser

Chrome and Edge (Chromium-based):

These browsers do not expose TLS version toggles in the UI since Chrome 84. TLS 1.0 and 1.1 are permanently disabled. If a site requires TLS 1.0 or 1.1, the site must be updated — there is no client-side workaround, nor should there be.

To check for experimental TLS flags, navigate to chrome://flags and search for TLS. In most production builds, no actionable flags will appear.

Firefox:

Navigate to about:config and search for security.tls.version.min. The value should be 3 (corresponding to TLS 1.2). Setting it to 1 or 2 to accommodate a broken server is a security risk and should only be done in isolated testing environments.

Internet Explorer / Legacy Edge:

Navigate to Internet Options > Advanced > Security and ensure Use TLS 1.2 and Use TLS 1.3 are checked. Uncheck Use SSL 3.0, Use TLS 1.0, and Use TLS 1.1.

7. Disable or Audit Browser Extensions

Extensions with network access — particularly VPNs, ad blockers, privacy tools, and proxy switchers — can intercept or modify TLS connections. To isolate an extension conflict:

Navigate to chrome://extensions/ and disable all extensions. Reload the failing page. If the error resolves, re-enable extensions one at a time, reloading after each, until the offending extension is identified.

8. Change DNS Resolver

DNS does not directly affect TLS, but a DNS resolver returning incorrect IP addresses (due to poisoning, filtering, or ISP interference) can direct your browser to a server that presents a certificate for the wrong domain, causing a ERR_CERT_COMMON_NAME_INVALID error.

Switching to a public resolver eliminates ISP-level DNS manipulation:

Windows — change DNS via PowerShell:

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","1.0.0.1")

Replace "Ethernet" with your actual interface name (use Get-NetAdapter to list interfaces).

Linux:

sudo nano /etc/resolv.conf

Add:

nameserver 1.1.1.1
nameserver 8.8.8.8

Recommended public resolvers:

9. Reset Network Stack (Windows)

A corrupted Winsock catalog or TCP/IP stack can cause intermittent TLS failures that appear unrelated to certificates. Run the following as Administrator:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

Restart the machine after running all five commands. Do not skip the restart — netsh winsock reset in particular requires a reboot to take effect.

Server-Side Fixes for Administrators

If you manage the web server presenting the certificate, the following are the most common server-side causes and their remediation.

Expired or Misconfigured SSL Certificate

An expired certificate is the single most common cause of this error at the server level. If you are running a site on a VPS Hosting environment, certificate renewal should be automated.

Check certificate expiry from the command line:

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

Automate renewal with Certbot (Let's Encrypt):

sudo certbot renew --dry-run

Add a cron job or systemd timer to run certbot renew twice daily — Let's Encrypt certificates expire every 90 days, and Certbot only renews when fewer than 30 days remain.

0 0,12 * * * root certbot renew --quiet

If you need a commercially validated certificate with extended validation or wildcard coverage, SSL Certificates from a trusted CA provide the chain of trust required for all major browsers.

Incomplete Certificate Chain

A very common misconfiguration: the server presents only the end-entity certificate without the intermediate CA certificates. The browser cannot build a trust path to a root CA it recognizes, resulting in ERR_CERT_AUTHORITY_INVALID.

Diagnose with SSL Labs:

Run your domain through SSL Labs Server Test (external tool). A chain issue will be flagged immediately.

Fix on Nginx:

The ssl_certificate directive must point to a file containing the full chain — your certificate followed by all intermediate certificates:

cat your_domain.crt intermediate.crt > fullchain.crt

ssl_certificate /etc/nginx/ssl/fullchain.crt;
ssl_certificate_key /etc/nginx/ssl/your_domain.key;

Fix on Apache:

SSLCertificateFile /etc/apache2/ssl/your_domain.crt
SSLCertificateKeyFile /etc/apache2/ssl/your_domain.key
SSLCertificateChainFile /etc/apache2/ssl/intermediate.crt

Deprecated TLS Versions and Weak Cipher Suites

Browsers have removed support for TLS 1.0 and TLS 1.1. If your server only offers these protocol versions, modern browsers will refuse the connection entirely.

Recommended Nginx TLS configuration:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_stapling on;
ssl_stapling_verify on;

Recommended Apache TLS configuration:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off

After modifying server configuration, test with:

openssl s_client -connect yourdomain.com:443 -tls1_2
openssl s_client -connect yourdomain.com:443 -tls1_3

Certificate Domain Mismatch

If your certificate covers www.example.com but users access example.com (or vice versa), the browser will report a domain mismatch. The correct fix is to issue a certificate with both names in the SAN field, or use a wildcard certificate (*.example.com).

When setting up a new domain on a Dedicated Servers environment, always verify the SAN field covers every hostname variant the server will respond to before going live.

Mixed Content Blocking

A page loaded over HTTPS that references HTTP resources (images, scripts, stylesheets) triggers mixed content warnings. While this does not produce the "can't provide a secure connection" error directly, it can cause partial page failures that are misdiagnosed as TLS errors.

Audit mixed content with:

curl -s https://yourdomain.com | grep -Eo 'src="http://[^"]*"|href="http://[^"]*"'

Comparing Client-Side vs. Server-Side Causes

Hosting Environment Considerations

The hosting environment you run directly influences how easily you can resolve server-side TLS issues.

On Shared Web Hosting, certificate management is typically handled through the control panel. Most modern shared hosting platforms include free Let's Encrypt integration, but you have limited control over server-wide TLS protocol settings.

On a VPS with cPanel, you gain access to AutoSSL for automated certificate provisioning and can configure Apache or Nginx TLS settings directly. This is the recommended environment for sites where TLS configuration precision matters.

On bare-metal Dedicated Servers, you have full control over the entire TLS stack — OpenSSL version, cipher suite selection, OCSP stapling, HSTS preloading, and certificate pinning — but you are also fully responsible for keeping the configuration current.

Practical Decision Checklist

Use this checklist to triage the error systematically rather than applying fixes at random:

• Does the error appear on all HTTPS sites or just one?
• All sites: focus on system clock, antivirus HTTPS scanning, browser update, OS root CA store.
• One site: the problem is almost certainly server-side.

• What does the specific error code say?
• ERR_CERT_DATE_INVALID: check system clock first, then certificate expiry.
• ERR_CERT_AUTHORITY_INVALID: check certificate chain completeness.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH: server is running deprecated TLS or unsupported ciphers.
• ERR_CERT_COMMON_NAME_INVALID: certificate SAN does not match the domain.

• Does the error disappear on a different network?
• Yes: firewall, proxy, or ISP-level TLS inspection is the cause.

• Does the error disappear with antivirus disabled?
• Yes: configure an exclusion for the domain in the antivirus HTTPS scanning settings.

• Are you the server administrator?
• Run openssl s_client diagnostics and SSL Labs test before touching any configuration file.
• Automate certificate renewal immediately after resolving the immediate issue.

FAQ

Why does "This site can't provide a secure connection" appear only on one website?

When the error is isolated to a single domain, the root cause is almost always server-side: an expired certificate, an incomplete certificate chain, a domain name mismatch in the certificate's SAN field, or the server being configured to use only deprecated TLS versions (1.0 or 1.1) that modern browsers no longer accept.

Can a VPN cause this error?

Yes. Some VPN clients route DNS queries through their own resolvers or perform traffic inspection that interferes with TLS handshakes. If the error appears only while the VPN is active, disable the VPN's "split tunneling" or "SSL inspection" feature, or add the affected domain as an exclusion.

Does clearing the cache always fix SSL errors?

No. Clearing the cache resolves errors caused by stale HSTS policies or cached invalid certificate responses. It has no effect on server-side certificate problems, system clock issues, or antivirus interception. Use cache clearing as a first step, not a universal solution.

How do I check if my server's SSL certificate is properly configured without a browser?

Use OpenSSL from any machine with network access:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

The output shows the full certificate chain, the negotiated TLS version, the cipher suite selected, and any verification errors. This is the most reliable diagnostic method for server-side TLS issues.

What is the difference between ERR_SSL_PROTOCOL_ERROR and ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

ERR_SSL_PROTOCOL_ERROR indicates the server sent a response that does not conform to any recognized TLS record format — often caused by a server sending an HTTP response on port 443, a misconfigured load balancer, or a firewall terminating the connection mid-handshake. ERR_SSL_VERSION_OR_CIPHER_MISMATCH means the handshake started correctly but the client and server could not agree on a mutually supported TLS version or cipher suite, typically because the server only supports deprecated protocols.