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

“Your connection is not private” is the red page Chrome shows when it cannot verify the certificate a site presented. Edge, Brave, Opera, and every other Chromium browser show the same page. Firefox calls it “Warning: Potential Security Risk Ahead” and Safari says “This Connection Is Not Private”. Under the headline, in small grey type, is an error code. The code is the actual diagnosis; the headline is just Chrome’s way of saying “certificate check failed.”

There are two very different situations behind this page:

• Every visitor sees it. The site’s certificate or server configuration is broken. The site owner has to fix it.
• Only you see it. Your device, network, or software is interfering with the check. The site is fine and the fix is on your side.

Start by finding out which one you are in, then use the code to pick the fix.

Step 1: Is it the site or is it you?

Load the same address on a phone using mobile data instead of Wi-Fi. If it loads there, the problem is your computer or network. If the phone shows the same warning, the problem is the site.

If you do not have a second device, run the domain through the SSL certificate checker. It connects from an independent server and reports the certificate’s dates, issuer, and hostname match. A clean result there with an error on your screen means the cause is local.

If you are seeing the warning on every site, not just one, skip ahead to certificate errors on all websites; that is nearly always a clock, an antivirus, or a Wi-Fi login page.

Step 2: Read the code

Click Advanced on the error page to see the full sentence, but the code alone is usually enough.

Code	Chrome’s reading	Most likely cause
NET::ERR_CERT_DATE_INVALID	The certificate’s dates do not include right now	Expired certificate, or the visitor’s clock is wrong
NET::ERR_CERT_AUTHORITY_INVALID	Issued by an authority the browser does not trust	Self-signed certificate, missing intermediate, antivirus or proxy interception, very old OS
NET::ERR_CERT_COMMON_NAME_INVALID	Certificate is for a different name	Certificate covers example.com but not www.example.com, or a CDN default certificate
NET::ERR_CERT_REVOKED	The authority revoked it	Key compromise or a certificate reissued after a mass revocation
NET::ERR_CERT_INVALID	Chrome could not parse it	Corrupt or malformed certificate file on the server
NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM	Signed with SHA-1 or weaker	Ancient certificate or internal CA
NET::ERR_SSL_VERSION_OR_CIPHER_MISMATCH	No shared TLS version or cipher	Server only offers TLS 1.0/1.1 or an obsolete cipher suite
NET::ERR_CERT_SYMANTEC_LEGACY	Old Symantec-issued certificate	Replace it; these are distrusted everywhere

Fixes when the problem is on your side

Your clock is wrong

The most common cause of a single person seeing this on many sites. A certificate is valid between two dates, and the browser checks them against your device’s clock. A dead motherboard battery, a restored virtual machine, or a phone that spent months in a drawer can leave the clock years off.

Fix: turn on automatic time. Windows: Settings → Time & language → Date & time → Set time automatically. macOS: System Settings → General → Date & Time → Set time and date automatically. Android and iOS have the same switch under Date & time. Reload the page.

Antivirus is scanning HTTPS

Avast, AVG, Kaspersky, Bitdefender, ESET, and others can decrypt your web traffic to scan it. To do that they present their own certificate to the browser. When their certificate is stale, or a browser update stops trusting it, you get ERR_CERT_AUTHORITY_INVALID on sites that are perfectly healthy. Click the padlock or “Not secure” label, view the certificate, and look at the Issued by line. If it names your antivirus vendor, that is the cause.

Fix: update the antivirus, or turn off its “HTTPS scanning”, “web shield”, or “encrypted connections scan” setting and reload.

You are behind a Wi-Fi login page

Hotel, airport, café, and campus networks intercept every request until you accept their terms. The intercept page presents its own certificate under the name of the site you asked for, so Chrome refuses it. Fix: open a plain http:// address such as http://neverssl.com, complete the login page, then retry.

A corporate proxy or filter

Employer networks and some school networks decrypt HTTPS for content filtering, exactly like antivirus does. The certificate issuer will be your organisation. Nothing on the website can change this; IT has to renew the proxy certificate or add an exception.

An old operating system

Windows 7, macOS before 10.12, Android before 7.1, and old Linux images are missing newer root certificates. Millions of sites use Let’s Encrypt, whose root certificate is not present on those systems, so they fail with ERR_CERT_AUTHORITY_INVALID. Fix: update the OS, or on Linux update the ca-certificates package. The command-line version of this problem is covered in curl (60): certificate has expired.

A VPN or DNS changer

Some free VPNs and “ad blocking DNS” services redirect blocked domains to their own servers, which cannot present a valid certificate for the domain. Disconnect the VPN or reset DNS to automatic and retry.

Stale browser state

Close the tab, clear the site’s data (padlock → Site settings → Clear data), or open an incognito window with extensions disabled. If incognito works and the normal window does not, an extension is interfering.

Fixes when the problem is the site

These are for the site owner. If you are a freelancer or agency and a client sent you a screenshot of this page, run the SSL certificate checker first; it tells you which of these you are dealing with.

The certificate has expired

NET::ERR_CERT_DATE_INVALID for everyone. Renew and reload the web server. The platform-by-platform steps for certbot, cPanel, Plesk, Cloudflare, IIS, and managed hosts are in Certificate has expired: how to fix it on any platform, and the reasons “automatic” renewal quietly stops are in why your SSL certificate expired without warning.

The name does not match

NET::ERR_CERT_COMMON_NAME_INVALID. The certificate was issued for example.com and the visitor typed www.example.com, or the other way round; or the DNS record points at a CDN or host that is serving its default certificate because the domain was never added there. Fix: reissue the certificate with both names, or add the domain to the CDN/host so it provisions its own. Then redirect one form to the other so visitors only ever land on one.

The intermediate certificate is missing

NET::ERR_CERT_AUTHORITY_INVALID for some visitors and not others. The server sends only the leaf certificate, and browsers that have not cached the intermediate cannot build the chain. Desktop Chrome often papers over this; Android and Firefox do not. Fix: install the full chain. With certbot, point the server at fullchain.pem, not cert.pem. With a purchased certificate, install the CA bundle your provider supplied.

The server is self-signed or uses an internal CA

Fine for a staging environment, wrong for anything a customer visits. Fix: issue a real certificate. Let’s Encrypt is free and every major host and panel supports it.

The server only offers old TLS

ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Modern browsers refuse TLS 1.0 and 1.1. Enable TLS 1.2 and 1.3 in the web server or load balancer configuration. Very old shared hosting is the usual home of this one.

The certificate was revoked

NET::ERR_CERT_REVOKED. Certificate authorities occasionally revoke large batches, and hosting providers do not always reissue automatically. Fix: request a new certificate from the authority and install it.

Can you just bypass it?

On a site without HSTS, Advanced → Proceed to example.com (unsafe) loads the page. On a site with HSTS, Chrome removes that link on purpose. Typing thisisunsafe on the error page still works in current Chrome, but reserve that for your own test server. Never tell customers or clients to click through; the warning exists because anyone on the network could be reading or altering the traffic.

Stop hearing about it from customers

For a visitor, the fix is a setting. For a site owner, the fix is renewal or configuration, but the underlying problem is that a browser warning was the first sign anything was wrong. By then every visitor has already been turned away.

Check the served certificate on a schedule instead. SitesRadar’s free plan monitors one site’s certificate and emails you 30, 14, and 7 days before it expires, and alerts you when the served certificate changes, alongside uptime, broken links, and DNS. If you look after several client sites, the SSL certificate expiration monitoring guide covers thresholds and an inventory you can run across all of them.

FAQ

Is “Your connection is not private” a virus? Almost never. It is the browser refusing a certificate. If you see it on every site and your clock is right, check whether your antivirus is scanning HTTPS before suspecting malware.

Why does the site work on my phone but not my laptop? Because the laptop’s clock, antivirus, VPN, or network is the cause. The site is fine.

I renewed the certificate and visitors still see the warning. The web server was not reloaded, a CDN or load balancer in front of it is still serving the old certificate, or the visitor has a stale tab. Reload the server, check the edge, and ask them to close the tab.

Does this mean the site is dangerous? It means the browser cannot prove who you are talking to. On a site you own, it is almost always a lapsed or misconfigured certificate. On an unknown site over public Wi-Fi, treat it as a real warning and do not enter passwords.