How to Fix "Your Connection Is Not Private"

"Your connection is not private" appears when the browser can't trust the site's certificate — it's expired, self-signed, issued for a different domain, or from an untrusted authority. The exact NET::ERR_ code under "Advanced" tells you which; owners fix that specific cause on the server.

What does this warning actually mean?

The red "Your connection is not private" page is Chrome's certificate interstitial. It is not a virus, a hack, or a sign that your computer is broken.

It means the browser tried to establish an encrypted HTTPS connection, asked the server to prove its identity with a TLS certificate, and decided it could not trust the answer. Until that trust is established, Chrome refuses to load the page and shows the warning instead. Firefox, Edge, and Safari display their own versions of the same block with slightly different wording.

The single most useful detail on the page is hidden. Click Advanced and you will see a short machine code such as NET::ERR_CERT_DATE_INVALID. That subcode is the key: it names the precise reason trust failed.

Two different certificates can both produce the same red page for completely different reasons, so reading the subcode before you do anything else saves a great deal of guesswork. The rules browsers apply when validating a certificate are defined by the CA/Browser Forum's Baseline Requirements.

The three subcodes you will meet most often are:

• NET::ERR_CERT_DATE_INVALID — the certificate has expired (or the start date is in the future, or your device clock is wrong). See the date-invalid guide.
• NET::ERR_CERT_AUTHORITY_INVALID — the certificate is self-signed or issued by an authority the browser does not recognise. See the authority-invalid guide.
• NET::ERR_CERT_COMMON_NAME_INVALID — the certificate is valid but was issued for a different domain name than the one in the address bar (a name mismatch). See the name-mismatch notes below.

Whichever subcode you see, the fix follows from it. The rest of this guide splits along the only line that matters: are you a visitor who just wants to read the page, or do you own the site and need to make the warning go away for everyone?

If you're just visiting

Start by reading the subcode under Advanced. It tells you whether the problem is on your side (a wrong clock, a captive portal) or on the site's side (an expired or misissued certificate). You cannot fix the site's certificate — only the owner can — but you can rule out the local causes quickly.

When "Proceed" is acceptable — and when it never is

Under Advanced, Chrome may offer a link to continue to the site anyway. On a site where you only read public information — a blog, a news article, a static reference page — proceeding is usually harmless if you understand the connection may not be private. The warning is telling you the truth: someone could, in theory, be intercepting the traffic.

Fix your device clock

A surprising share of certificate warnings come from a wrong date or time on your own device. TLS certificates are only valid between two dates. If your clock is set days or years off, the browser thinks a perfectly good certificate has expired or has not started yet, and you get NET::ERR_CERT_DATE_INVALID on every HTTPS site at once.

Open your system settings and turn on automatic date and time (and the correct time zone), then reload. This is the single fastest thing to try when the warning appears everywhere.

Public Wi-Fi and captive portals

On hotel, airport, or cafe Wi-Fi you often have to accept terms or sign in on a "captive portal" page before you get real internet access. Until you do, the network quietly redirects your requests to its own sign-in page. Because that page is not the site you asked for, the certificate doesn't match and you see the warning.

The fix is not to click through: open a plain HTTP page (many devices auto-open the portal), complete the sign-in, and the warnings disappear on their own once you have genuine connectivity.

If you own the site

If visitors report this on your site, the certificate is genuinely failing for them and you need to fix it on the server. Read the subcode, then apply the matching fix. The warning will clear for everyone once the underlying certificate problem is resolved — there is nothing to change in the visitor's browser.

• NET::ERR_CERT_DATE_INVALID — your certificate has expired. Renew or reissue it and reinstall the new certificate, then confirm auto-renewal is working so it does not lapse again. Most outages of this kind are simply a missed renewal.
• NET::ERR_CERT_AUTHORITY_INVALID — you are serving a self-signed certificate, or the intermediate (chain) certificate is missing. Install a certificate from a publicly trusted authority and make sure the full chain — your certificate plus the intermediates — is served. A missing intermediate is the most common cause of an otherwise valid certificate being rejected.
• NET::ERR_CERT_COMMON_NAME_INVALID — the certificate does not cover the exact hostname being requested. Reissue it with every hostname you serve listed in the Subject Alternative Name field. The classic case is a certificate that covers example.com but not www.example.com (or the reverse).

After any change, do a clean check from outside your own machine — browser caches and local trust settings can mask a problem that visitors still see. Confirm the expiry date, the full chain, and that every hostname you serve is listed.

A configuration line such as this in your server block is where the certificate and its chain are wired up; the chain file must contain the intermediates, not just your leaf certificate:

# nginx
ssl_certificate     /etc/ssl/fullchain.pem;   # leaf + intermediates
ssl_certificate_key /etc/ssl/privkey.pem;

Why does a valid certificate still show this?

Once you have read the subcode and matched it to a cause, "Your connection is not private" stops being a mysterious red wall and becomes a specific, fixable problem.