“This site can’t provide a secure connection”: how to fix it

“This site can’t provide a secure connection” is Chrome’s way of telling you that the HTTPS connection to the site failed. The browser tried to establish an encrypted connection, something went wrong during the process, and Chrome refused to load the page rather than risk an insecure connection. Firefox shows a similar message as “Secure Connection Failed” or “SEC_ERROR_UNKNOWN_ISSUER.” Safari displays “Safari can’t establish a secure connection to the server.”

This is not a single error with a single cause. It is an umbrella message that covers multiple distinct SSL/TLS failures, from expired certificates to TLS version mismatches to local system clock issues. The fix depends entirely on which specific failure triggered the message. This guide covers the server-side causes, the client-side causes, and how to tell the difference.

What the error actually means#

When you visit an HTTPS site, your browser performs a TLS handshake with the server before loading any content. During this handshake, the server presents its SSL certificate, the browser verifies the certificate is valid and trusted, and both sides negotiate an encryption method. If any part of this process fails, the browser displays a security warning and blocks the page.

The “can’t provide a secure connection” message appears when the failure is severe enough that the browser does not even offer a “proceed anyway” option. Less severe certificate issues (like an expired certificate) may show as “Your connection is not private” with an option to continue at your own risk. The “can’t provide a secure connection” message means the failure is at the protocol level, not just the certificate level.

The exact Chrome error code appears in smaller text below the main message. Common codes include:

• ERR_SSL_PROTOCOL_ERROR – the TLS handshake failed entirely
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH – the browser and server cannot agree on encryption parameters
• ERR_CERT_COMMON_NAME_INVALID – the certificate does not cover the domain you are visiting
• ERR_CERT_DATE_INVALID – the certificate has expired or is not yet valid
• ERR_CERT_AUTHORITY_INVALID – the certificate was issued by an untrusted authority
• ERR_CONNECTION_CLOSED – the server closed the connection during the handshake

Each of these has different causes and different fixes. Check the error code to narrow down the diagnosis.

Server-side causes#

These are problems on the web server that affect all visitors. If the site is yours, these are the issues you need to fix.

Expired SSL certificate

The most common cause of secure connection errors across the internet. SSL certificates have expiration dates, typically 90 days for Let’s Encrypt certificates and 1 year for commercial certificates. When the certificate expires, browsers immediately stop trusting it and display a security error.

Check when your certificate expires:

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

This shows the notBefore and notAfter dates. If notAfter is in the past, the certificate has expired.

Fix: Renew the certificate. If you use Let’s Encrypt with certbot:

certbot renew
systemctl reload nginx

If automatic renewal was configured and the certificate still expired, check the certbot renewal logs at /var/log/letsencrypt/letsencrypt.log for errors. Common causes of renewal failure: DNS records changed, the server is behind a proxy that blocks the HTTP-01 challenge, or port 80 is not reachable. For a full walkthrough of certificate installation and renewal, see How to install an SSL certificate.

On Hostney, SSL certificates are provisioned and renewed automatically. If you see an expiration error on a Hostney-hosted site, contact support. Automatic renewal may have failed due to a DNS misconfiguration or a domain that was recently added.

Certificate does not cover the domain

The SSL certificate must include the exact domain the visitor is using. A certificate for example.com does not cover www.example.com unless it includes both as Subject Alternative Names (SANs). A certificate for example.com does not cover shop.example.com unless it is a wildcard certificate ( *.example.com ).

Check which domains the certificate covers:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep "DNS:"

This lists all domains in the certificate’s SAN field. If the domain the visitor is using is not in this list, the certificate does not cover it.

Fix: Issue a new certificate that includes all the domains your site uses. With certbot:

certbot certonly --nginx -d example.com -d www.example.com

Include every domain and subdomain that points to this server. A common mistake is issuing a certificate for example.com only and forgetting www.example.com , or vice versa.

Self-signed certificate

A self-signed certificate is one that was not issued by a trusted Certificate Authority (CA). The server created and signed it itself. Browsers do not trust self-signed certificates because there is no third party verifying that the server is who it claims to be.

Self-signed certificates are sometimes used for development, staging, or internal services. They provide encryption but not trust verification. If your production site is using a self-signed certificate, browsers will show a security error for every visitor.

Fix: Replace the self-signed certificate with one from a trusted CA. Let’s Encrypt provides free certificates that are trusted by all major browsers. There is no reason to use a self-signed certificate on a public-facing production site.

Incomplete certificate chain

SSL certificates are organized in a chain of trust: your certificate is signed by an intermediate CA, which is signed by a root CA that browsers trust. Your server must send the full chain (your certificate plus any intermediate certificates) during the TLS handshake. If the intermediate certificate is missing, some browsers can fill in the gap by fetching it separately, but others cannot and will fail with a secure connection error.

Check your certificate chain:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | grep -E "depth|verify"

If you see “unable to verify the first certificate” or the chain is incomplete, you are missing an intermediate certificate.

Fix: Configure your web server to send the full chain. In Nginx, the ssl_certificate directive should point to a file that contains your certificate followed by the intermediate certificate(s):

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

The key is fullchain.pem , not cert.pem . The fullchain file includes both your certificate and the intermediate certificates. Using cert.pem (which contains only your certificate) will cause chain validation failures in some browsers and tools.

Outdated TLS version

Browsers have dropped support for TLS 1.0 and TLS 1.1. If your server only supports these older versions and not TLS 1.2 or 1.3, modern browsers will refuse to connect. This produces the ERR_SSL_VERSION_OR_CIPHER_MISMATCH error specifically.

Check which TLS versions your server supports:

# Test TLS 1.2
openssl s_client -tls1_2 -connect example.com:443 < /dev/null 2>&1 | head -5

# Test TLS 1.3
openssl s_client -tls1_3 -connect example.com:443 < /dev/null 2>&1 | head -5

If TLS 1.2 fails, your server is using an outdated configuration.

Fix: Update your Nginx SSL configuration to support modern TLS versions:

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;
ssl_prefer_server_ciphers off;

Then reload Nginx:

nginx -t && systemctl reload nginx

For a detailed guide on TLS handshake failures, see ERR_SSL_PROTOCOL_ERROR: what it means and how to fix it.

HTTPS not configured on the server

If the server does not have SSL configured at all but the visitor is accessing the site via https:// , the connection fails immediately. Nothing is listening for HTTPS connections, or the server is listening but does not have a certificate to present.

This commonly happens when:

• A new site was set up and HTTPS was not configured
• DNS was pointed to a new server but SSL certificates were not installed yet
• A server migration moved the site but the certificate was not migrated

Fix: Install an SSL certificate. With certbot and Nginx:

certbot --nginx -d example.com -d www.example.com

If the site is behind Cloudflare and HTTPS is not configured on the origin, Cloudflare may show 520 or 521 errors instead of a browser-level SSL error, because Cloudflare handles the browser-facing HTTPS connection and the failure is between Cloudflare and your origin.

Wrong certificate served (SNI issue)

If your server hosts multiple sites, it uses Server Name Indication (SNI) to determine which certificate to serve based on the domain the visitor requested. If the Nginx configuration has the wrong server_name or the wrong ssl_certificate directive for a virtual host, visitors to that domain may receive a certificate meant for a different domain.

Check which certificate the server actually serves:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -subject -issuer

If the subject shows a different domain than the one you are visiting, the wrong certificate is being served.

Fix: Check your Nginx configuration for the affected domain. Make sure the server_name directive matches the domain and the ssl_certificate directive points to the correct certificate for that domain.

Client-side causes#

These are problems on the visitor’s computer, not on the server. If the site works for other people but not for you, start here.

System clock is wrong

SSL certificates are valid for a specific time period. If your computer’s clock is set to the wrong date, a valid certificate may appear expired (clock too far in the future) or not yet valid (clock too far in the past). This is more common than you would think, especially on machines that have had their batteries die or that have incorrect timezone settings.

Fix: Check your system date and time. On Windows, right-click the clock in the taskbar and select “Adjust date/time.” Make sure “Set time automatically” is enabled. On macOS, go to System Settings > General > Date & Time and enable automatic date and time.

Cached SSL state in the browser

Browsers cache SSL session data and certificate information. If a site recently renewed or replaced its certificate, your browser may still be using cached data from the old certificate, causing a validation failure.

Fix: Clear your browser’s SSL state. In Chrome on Windows: Settings > Privacy and Security > Security > Manage device certificates, or clear browsing data with “Cached images and files” selected. Try loading the site in an incognito window first to confirm whether the cache is the issue.

Browser extensions or antivirus intercepting HTTPS

Some antivirus software and browser extensions perform HTTPS inspection by inserting their own certificate into the connection between your browser and the server. This is technically a man-in-the-middle operation (done for security scanning purposes). If the antivirus certificate is expired, misconfigured, or not trusted by the browser, it causes secure connection errors on every HTTPS site, not just one.

Common culprits: Avast, AVG, Kaspersky, ESET, and Bitdefender all have HTTPS scanning features that can interfere. Some corporate proxies (Zscaler, Blue Coat) do the same thing.

Fix: If the error appears on every HTTPS site, temporarily disable your antivirus’s web protection or HTTPS scanning feature. If the error goes away, the antivirus is the cause. Update the antivirus or add an exception for the affected site.

VPN or proxy interference

VPNs and proxy servers can interfere with SSL connections by routing traffic through servers that alter headers, inject certificates, or block certain TLS configurations. Some corporate proxies intentionally block connections that they cannot inspect.

Fix: Disconnect the VPN or proxy and try loading the site directly. If it works without the VPN, the VPN provider’s infrastructure is interfering with the SSL connection.

Outdated browser

Very old browsers may not support TLS 1.2 or modern cipher suites. If the server requires TLS 1.2+ (which it should), an old browser that only supports TLS 1.0 or 1.1 will fail to connect.

Fix: Update your browser. All current versions of Chrome, Firefox, Safari, and Edge support TLS 1.2 and 1.3.

How to diagnose: server or client?#

The first question is always: does the error affect everyone or just you?

Test from multiple locations:

# Test from the command line (bypasses browser-specific issues)
curl -Iv https://example.com 2>&1 | head -20

If curl succeeds, the server is fine and the issue is browser-specific. If curl also fails, the problem is server-side.

Test from an online tool: Use an SSL checker like tools.hostney.com/ssl, SSLLabs.com, or SSLShopper.com to test your certificate from an external perspective. These tools show expiration dates, chain completeness, TLS versions supported, and any configuration issues.

Test in an incognito window: If the site loads in incognito but not in your normal browser, the issue is cached data, an extension, or a local certificate override.

Test on a different device: If the site works on your phone but not your laptop, the issue is specific to your laptop’s configuration (antivirus, VPN, clock, cached state).

Quick reference#

For related SSL errors with dedicated guides, see ERR_SSL_PROTOCOL_ERROR and ERR_SSL_VERSION_OR_CIPHER_MISMATCH. For understanding the differences between certificate types, see Free vs paid SSL certificates. For a complete list of WordPress errors, see How to fix the most common WordPress errors.