Is "Your connection is not private" a virus?

No. It's the browser refusing an HTTPS connection because it couldn't verify the site's TLS certificate. The usual causes are an expired certificate, a missing intermediate, a domain mismatch, or a wrong clock on your device, not malware.

Should I click "Proceed anyway" to get past it?

Only on a site you own and are actively debugging. On any site handling logins or payments, the warning means the encrypted connection can't be verified, so proceeding is a real risk. Fix the certificate instead of bypassing the check.

Why does the site work for me but not for others?

Almost always a missing intermediate certificate. Your browser cached the intermediate from an earlier visit, so it completes the chain locally while fresh browsers can't. Reinstall the full chain bundle on the server to fix it for everyone.

How to Fix "Your Connection Is Not Private"

VigilDog Team · October 3, 2026 · 6 min read

Few browser messages cause more panic than "Your connection is not private." It looks like your whole site is broken, and for visitors, it effectively is, most turn back at that red screen. The good news: the message is a symptom with a small set of causes, and once you read the error code the browser hides underneath it, the fix is usually quick. Here's how to diagnose and clear it.

What the error is really telling you

"Your connection is not private" doesn't mean someone is intercepting your traffic. It means the browser tried to establish a secure HTTPS connection and couldn't verify the site's TLS certificate, so it refuses to continue rather than risk it. The browser is failing safe.

The single most useful move is to reveal the underlying error code, which tells you exactly which check failed. In Chrome, click "Advanced" on the warning page, or open DevTools and check the Security tab. You'll see a specific code like NET::ERR_CERT_DATE_INVALID or NET::ERR_CERT_AUTHORITY_INVALID. That code is your diagnosis, everything below maps a code to a fix.

How certificate validation works

To fix the error, it helps to know what the browser is checking. When you connect over HTTPS, the server presents its certificate along with any intermediate certificates. The browser walks this chain from your site's certificate up to a root it already trusts, verifying each link's signature. It also checks that the certificate hasn't expired and that the domain name matches.

Any broken link, an expired cert, a missing intermediate, a name mismatch, an untrusted issuer, halts the chain and triggers the warning. The diagram below shows the chain the browser has to validate. Most real-world failures are one of these four breaks.

The TLS certificate chain of trust

Fix by error code

Match the code you found to its cause and remedy:

NET::ERR_CERT_DATE_INVALID, the certificate expired (or your device clock is wrong). If the clock is right, the cert lapsed; renew and reinstall it. See our SSL certificate expired guide for the full renewal walkthrough.
NET::ERR_CERT_AUTHORITY_INVALID, the browser doesn't trust the issuer, usually a missing intermediate certificate. Reinstall the full chain (your cert + the CA's intermediate bundle), not just the leaf certificate.
NET::ERR_CERT_COMMON_NAME_INVALID, the certificate doesn't cover the domain you visited, e.g. a cert for example.com served on www.example.com. Reissue with the right names or a SAN/wildcard that covers both.
NET::ERR_CERT_REVOKED, the CA revoked the certificate. You'll need to reissue a fresh one; don't try to force through this.
SSL_ERROR_BAD_CERT_DOMAIN or a self-signed warning, you're serving a self-signed or default certificate. Install a certificate from a trusted CA (Let's Encrypt is free).

The missing-intermediate trap

This one deserves its own note because it's the most common fix that people get wrong. Your certificate authority issues your certificate signed by an intermediate CA, not directly by the trusted root. Servers must send that intermediate alongside your certificate so the browser can complete the chain.

Desktop Chrome sometimes caches intermediates from earlier visits and papers over the gap, which is why a site can look fine on your machine but throw "not private" on a colleague's phone or a fresh browser. The fix is to install the CA's full chain bundle (often named fullchain.pem or a .ca-bundle file) rather than the standalone certificate. Test with SSL Labs or run your domain through our SSL checker, which flags a broken chain even when your own browser hides it.

When it's your device, not the site

If the error appears on every HTTPS site you visit, the problem is local. Check the obvious things: a wrong system clock breaks date validation instantly, so confirm the date and time are correct and set to sync automatically. Public Wi-Fi captive portals also trigger it before you've logged in, open a plain HTTP page to force the login screen.

Antivirus or corporate proxies that intercept HTTPS can inject their own certificates and cause mismatches, and stale browser cache occasionally holds a bad certificate; an incognito window quickly tells you whether cache is the culprit. But if the error shows up for visitors and not just you, treat it as a server-side certificate problem and work the error code, don't tell customers to fix their clocks.