Your Connection Is Not Private: What It Means and How to Fix It

"Your connection is not private" is one of the most common warnings on the web, and one of the most alarming. Instead of the page you wanted, the browser shows a red warning, a padlock with a slash through it and an error code like NET::ERR_CERT_DATE_INVALID. Most people close the tab. For a visitor that's mildly annoying. For the business behind the site, it means almost every visitor is turned away until someone fixes it.

This guide explains what the warning actually means, how to read the error code under it, how to fix it as a visitor, and how to fix it on your own website. It also covers why this error is getting more common in 2026, and how to make sure your site never shows it to customers.

What does "Your connection is not private" mean?#

When you open a site over HTTPS, the server sends your browser an SSL/TLS certificate. The certificate proves two things: that the site really is the domain in the address bar, and that the connection between you and the server is encrypted.

Before showing the page, the browser checks that certificate. It asks:

1. Is the certificate within its valid dates?
2. Was it issued by a certificate authority (CA) the browser trusts?
3. Does it cover the exact hostname you visited?
4. Is the chain of certificates from the site up to the trusted root complete?
5. Has it been revoked?

If any answer is no, the browser can't confirm it's talking to the real site, so it stops and shows "Your connection is not private". It's a protection, not a bug. The warning exists because someone could be intercepting the connection, even though in practice the cause is usually a mistake on the website's side.

What it looks like in each browser#

The wording changes from browser to browser, but the meaning is the same:

The code under the warning is the most useful part. It tells you which check failed.

The error codes and what they mean#

On the visitor side, ERR_CERT_DATE_INVALID is often caused by a wrong date on the device. On the site side, the same code is the classic sign of an expired certificate.

Is it safe to click "Proceed anyway"?#

Usually no. On a site you've never used, at a cafe or on public Wi-Fi, don't continue, and never type a password or card number past this warning.

There are narrow exceptions, like your own development server or a router admin page on your home network, where a self-signed certificate is expected. Even then, the right fix is a valid certificate, not clicking through.

On some sites there's no "Proceed" link at all. That happens when the site uses HSTS (HTTP Strict Transport Security), which tells browsers to never accept an invalid certificate for that domain. That's working as intended.

How to fix "Your connection is not private" as a visitor#

If the warning appears on a well-known site that normally works, the problem is often on your side. Try these in order:

1. Reload the page. A brief network hiccup can cause a one-off failure.
2. Check your device's date and time. If your clock is wrong, every valid certificate can look expired or not yet valid. Turn on automatic date and time, then reload.
3. Check if you're on public Wi-Fi. Hotels, airports and cafes often show a login page first. Open a plain HTTP site, such as http://neverssl.com, to trigger the login page, then try again.
4. Try a private window. If it works there, clear the cache and cookies for that site.
5. Turn off a VPN or proxy and try again.
6. Check your antivirus. Some security software inspects HTTPS traffic and can break certificate checks. Look for an option like "HTTPS scanning" or "encrypted connection scanning" and update or disable it.
7. Update your browser and operating system. Very old systems don't trust newer root certificates.
8. Try another device or network. If the warning appears everywhere, the problem is the website, and only its owner can fix it.

How to fix "Your connection is not private" on your website#

If visitors report the warning on your site, or you see it yourself on every device, work through these steps.

1. Check the certificate the server is actually serving#

Don't assume the certificate you installed is the one visitors get. Check it from outside with the free SSL Certificate Checker, which shows the expiry date, issuer, covered hostnames and whether the chain is complete.

From the command line:

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

The notAfter line is the expiry date. The -servername flag matters, because servers that host several sites can return a different certificate without it.

2. Renew an expired certificate#

If the certificate has expired, renew it and reload the web server.

• Let's Encrypt with Certbot: run sudo certbot renew, then reload nginx or Apache. Use sudo certbot renew --dry-run to test that future renewals will work.
• Managed hosting: most hosts renew automatically. If yours didn't, look for an SSL or TLS section in the control panel and reissue the certificate.
• Paid certificates: reissue through your CA and install the new certificate and intermediate bundle.

Then find out why auto-renewal failed, or it will happen again. Common reasons are DNS changes, a firewall blocking the validation request, a CAA record that doesn't allow your CA, or a server that renewed the file but was never reloaded. Our guide to checking SSL certificate expiration covers these in detail.

3. Cover every hostname#

A certificate only works for the names listed in it. If it covers example.com but visitors reach www.example.com, they get NET::ERR_CERT_COMMON_NAME_INVALID.

Make sure the certificate includes every hostname people use: the bare domain, www, and any subdomains like shop or app. Then redirect the extra hostnames to your main one with a 301. Our 301 vs 302 guide explains which redirect to use.

4. Install the full certificate chain#

Browsers need the chain from your certificate to a trusted root. If the server sends only your certificate without the intermediate certificate, some browsers and devices show NET::ERR_CERT_AUTHORITY_INVALID while others work fine, which makes the problem confusing to debug.

On nginx, point ssl_certificate at the full chain file (with Let's Encrypt, that's fullchain.pem, not cert.pem). On Apache 2.4.8 and later, use a full chain file in SSLCertificateFile.

5. Replace self-signed certificates#

Self-signed certificates are fine on a laptop but always trigger the warning on a public site. Use a free certificate from Let's Encrypt or one provided by your host or CDN.

6. Check your CDN settings#

If you use Cloudflare or another CDN, there are two certificates: one between the visitor and the CDN, and one between the CDN and your server. Make sure the edge certificate covers your hostnames, and use Cloudflare's Full (strict) SSL mode with a valid certificate on your origin. A mismatch between these settings is also a common cause of redirect loops, covered in our guide to ERR_TOO_MANY_REDIRECTS.

7. Fix the server's TLS configuration#

If visitors see ERR_SSL_VERSION_OR_CIPHER_MISMATCH, the server is offering only outdated protocols or ciphers. Enable TLS 1.2 and TLS 1.3 and use a current recommended cipher list, such as the Mozilla SSL Configuration Generator's "intermediate" profile.

Why this error is getting more common in 2026#

Certificates are getting shorter. The CA/Browser Forum, the group that sets the rules for public certificates, has approved a phased cut in maximum certificate lifetimes:

Shorter certificates are safer, but they mean more renewals. A site that renewed once a year now renews about twice a year, and by 2029 roughly every month and a half. Every renewal is another chance for automation to fail quietly. On top of that, Let's Encrypt stopped sending expiration warning emails in June 2025, so many site owners lost their only reminder.

The result: expired certificates, one of the most avoidable outages on the web, are becoming easier to miss.

Does "Your connection is not private" hurt SEO?#

Indirectly, yes. Googlebot can still crawl a page with a certificate problem, but every real visitor from Google hits a warning wall and leaves, so you lose the traffic, conversions and trust immediately.

There are knock-on effects too:

• Payments and forms can fail, because payment providers and APIs refuse invalid certificates.
• Integrations break. Webhooks, apps and feeds that call your site over HTTPS stop working.
• Long outages look like a broken site. If the problem lasts for days, users bounce back to search results and pick a competitor.

The fix is quick once you know about it. The damage comes from the hours or days it goes unnoticed.

How to make sure your site never shows this warning#

Most certificate failures are predictable. The expiry date is printed right in the certificate. The risk is that nobody is watching it.

MyKavo checks the SSL certificate on every website you monitor, on every plan including Free:

• Expiry reminders 14 days before the certificate expires, then again at 7, 3 and 1 days, so there's time to fix a failed renewal.
• Uptime checks every 5 minutes, with an alert after two failed checks in a row, so you hear about an outage before your customers do.
• Page scans against an approved baseline, which flag critical changes like a page that starts returning errors, a removed canonical tag or a new noindex.

It's on by default, with nothing to install on your server.

The bottom line#

"Your connection is not private" means the browser couldn't trust the site's certificate. If it happens everywhere for you, check your device's clock, network and security software. If it happens on your website, check the certificate the server is actually serving, then renew it, cover every hostname, install the full chain and fix your CDN settings.

With certificate lifetimes shrinking every year, renewals will only get more frequent. Check your certificate now with the free SSL Certificate Checker, then start free with MyKavo to get reminders before any certificate on any of your sites expires.