Your connection is not private: which of the five certificate faults you have

“Your connection is not private” is Chrome refusing to load the page because it can’t trust the site’s certificate. Underneath the headline it prints a code beginning NET::ERR_CERT_, and that code tells you which of five faults you’re looking at: an expired certificate, a self-signed or untrusted one, a certificate for the wrong hostname, a missing intermediate, or no HTTPS at all. Find the code you were shown below, read that section, and you’ll know what to fix. Firefox shows the same faults under a different headline, “Warning: Potential Security Risk Ahead”, with its own code names, so if you came from Firefox, match on the description rather than the string.

Plenty of sites show this screen. Of the 212,154,494 domains where a TLS handshake completed in the September 2026 census, 23,036,743 (10.9%) presented a certificate that would trigger it.

NET::ERR_CERT_DATE_INVALID: expired, or the clock is wrong

This is the commonest of the five. The certificate has a “not after” date and today is past it, so the browser treats it as void. Certificates from the free issuers run for ninety days, so one renewal job failing unnoticed is enough to put you here.

There’s a second cause hiding under the same code. If the visitor’s device clock is wrong, the browser compares the certificate’s dates against a date that doesn’t exist yet, or one long gone, and prints exactly this string. Before you touch the server, open the site from a phone on mobile data. If the phone loads it cleanly, the certificate is fine and the laptop’s clock is the problem.

To confirm expiry from a terminal, ask the server for its dates directly:

openssl s_client -connect yourdomain.tld:443 -servername yourdomain.tld </dev/null 2>/dev/null | openssl x509 -noout -dates

A notAfter in the past confirms it. The same handshake also prints Verify return code: 10 (certificate has expired) near the bottom.

NET::ERR_CERT_AUTHORITY_INVALID: the browser doesn’t know who signed it

This code covers two faults that look identical from the visitor’s chair and need different fixes on the server. The openssl output separates them.

Self-signed, or issued by an authority the browser doesn’t carry

A self-signed certificate is one the server signed for itself. It encrypts the connection, but no browser will ever trust it, because trust comes from a chain back to a root the browser already holds. The same applies to certificates from a private or internal authority that has never been added to the public root stores. Among the 212,160,994 certificates the September 2026 census collected, 4,160,496 were self-signed. In the handshake output you’ll see Verify return code: 18 (self signed certificate) and the issuer line will match the subject line.

Incomplete chain: the intermediate is missing

Public certificates are rarely signed by a root directly. The root signs an intermediate, the intermediate signs your certificate, and the server is meant to send both yours and the intermediate so the browser can build the path. If the server sends only the leaf, some browsers fill the gap from cache and others don’t, which is why the site “works for me” and fails for the person who reported it. Chrome usually reports this as NET::ERR_CERT_AUTHORITY_INVALID even though the certificate itself is valid, so the code alone doesn’t tell you which. In the terminal you’ll see Verify return code: 21 (unable to verify the first certificate), and the issuer line will name a real authority rather than repeating the subject, which tells you the certificate is fine and the server isn’t sending the intermediate.

NET::ERR_CERT_COMMON_NAME_INVALID: right certificate, wrong hostname

The certificate is in date and properly signed, but it’s for a different name. The usual shape is a certificate that covers the bare domain while the site also answers on www, or the reverse, and the visitor typed the one you forgot. It also shows up after a rename, when the site moves to a new hostname and keeps serving the old certificate.

Check the names on the certificate rather than guessing:

openssl s_client -connect yourdomain.tld:443 -servername yourdomain.tld </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Each hostname the site answers on must appear in that subjectAltName list. A missing www is the usual cause when this code appears, and one reissue clears it.

No code at all: the site has no HTTPS

If port 443 isn’t listening, or answers with plain HTTP, the browser has nothing to evaluate and you’ll see a connection-refused or protocol error instead of a certificate code, sometimes with the “not private” wording and sometimes with “This site can’t provide a secure connection”. Either way, the fix starts one step earlier than the other four: you need a certificate and an HTTPS listener before any of the trust checks can run. A site in this state is also what produces the inline “Not secure” label in the address bar; the full-page block and the small label share a root cause and differ in severity.

You’ve now matched your code to a fault. Run the free scan to confirm which fault the internet sees from outside, including the chain and the date, before you change anything.

Owner or visitor: which side of the warning you’re on

If you run the site, you’re looking at a configuration fault, and you can fix it yourself in an afternoon. Nobody has broken in. The warning is the browser doing its job on your behalf, refusing to vouch for a connection it can’t verify.

If you’re a visitor on someone else’s site, treat the screen as a stop sign. The connection may be neither encrypted nor authentic, so don’t type a password, a card number, or anything you’d mind a stranger reading. Clicking “proceed anyway” gets you past the warning but leaves the fault where it was, and if you own the site it fixes nothing.

Fixing it, in order

Each step below clears one of the faults above, and taking them in this order means you don’t reissue a certificate twice.

Reissue or renew first. A fresh certificate from any public authority clears the expiry fault on the spot and, if the old one was self-signed, clears that too. Let’s Encrypt issued 118,235,223 (55.73%) of the 212,160,994 certificates the September 2026 census collected, so the free route is also the ordinary one, and any ACME client will fetch you one.

When you request it, cover every hostname the site answers on. That means the bare domain and www together, or a wildcard for the whole zone. This clears the common-name fault and stops it returning the next time someone adds a subdomain.

Install the full chain. Your ACME client will hand you a fullchain.pem alongside cert.pem; point the server at the full one. If you’ve pasted certificates into a control panel by hand, paste the intermediate into the field labelled “CA bundle” or “chain”, and rerun the openssl command above until the verify return code reads 0 (ok).

Automate renewal so the expiry fault can’t come back. ACME clients ship with a timer or cron entry; check that it’s enabled, then check that it ran by looking at the notAfter date a day after the scheduled time. Watch for a renewal job that writes the new certificate to disk but never reloads the web server, because then the file is current and the one being served is still the expired one.

Force HTTP to HTTPS and add HSTS last. Redirect port 80 to 443, then send the header:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Once a browser has seen that header, it stops offering the “proceed anyway” link on certificate errors for your host, so a lapse turns from an ugly warning into a hard outage. That’s the behaviour you want, because it’s the same behaviour that protects your visitors from a forged certificate, and it’s why renewal automation goes in before HSTS does. The HSTS piece covers preload and the subdomain trap in detail.

Keeping it fixed

Certificates cost nothing and renewal can be automated, so once the setup is done there’s nothing left to pay for. The work that stays is monitoring: a check that reads notAfter from outside and warns you at fourteen days is worth more than any amount of care at issue time, because the failure mode is a job that stops running while nobody is looking.

The certificate is one part of the TLS posture a browser evaluates before it trusts you, alongside the protocol version and the cipher on offer, and the response headers you send on top of that connection decide what a page is allowed to do once it’s loaded. Clearing this warning fixes the loudest problem, and the scan report lists whatever else is sitting next to it.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.