← Blog

Your connection is not private — what the warning actually means and how to fix it

May 6, 2026

By Nick Phillips, Founder

If you've landed on this page, one of three things just happened:

1. A site you run is showing visitors a red warning page and you need to fix it.
2. A site you don't run is showing you a warning page and you want to know whether it's safe to proceed.
3. You're trying to understand a specific error code (NET::ERR_CERT_AUTHORITY_INVALID, SEC_ERROR_UNKNOWN_ISSUER, NET::ERR_CERT_DATE_INVALID, etc.) and want a translation.

This post covers all three.

What the warning actually means

"Your connection is not private" (Chrome / Edge), "Warning: Potential Security Risk Ahead" (Firefox), and "This Connection Is Not Private" (Safari) all mean the same thing underneath: the browser tried to verify the site's TLS certificate and the verification failed. Something about the cert didn't add up, so the browser refused to assume the connection is safe.

That's not the same as "the connection is being attacked." It just means the browser can't tell the difference between "legitimately broken cert" and "active attacker doing something hostile." From the browser's point of view those two cases look identical, so it errs on the side of warning you.

The specific reason is what the error code tells you.

The error codes, decoded

NET::ERR_CERT_AUTHORITY_INVALID / SEC_ERROR_UNKNOWN_ISSUER

What it means: the cert was issued by a CA the browser doesn't trust. Either it's self-signed, or it's signed by a private/internal CA, or the public CA's root isn't in the browser's trust store.

Common causes:

• Self-signed certificate (the most common — you generated a cert with openssl req and didn't get it signed by a real CA).
• Corporate intranet site signed by an internal CA that isn't installed on this machine.
• Cert is real but the intermediate chain isn't being served (browser can find the leaf but can't trace it back to a root).
• Antivirus or "internet security" software intercepting TLS with its own root that this browser doesn't trust.

How to actually fix it (as the site owner): get a cert signed by a public CA. Let's Encrypt is free and fast. If you're running a real public site and you're seeing this error in production, the answer is almost always "use Let's Encrypt" — there's no remaining good reason to ship self-signed certs to public users.

How to check the chain issue specifically:

echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null

The output should show two or three certs. If it only shows one, your server isn't sending the intermediate, and you need to fix your server config to include the full chain (nginx: use fullchain.pem not cert.pem; apache: SSLCertificateChainFile or concatenate into SSLCertificateFile).

NET::ERR_CERT_DATE_INVALID / SEC_ERROR_EXPIRED_CERTIFICATE

What it means: the cert is expired (or in rare cases, not-yet-valid because the notBefore is in the future, often a clock-skew issue).

Common causes:

• Cert literally expired and nobody renewed it.
• Renewal job ran but the webserver wasn't reloaded — see our Let's Encrypt renewal failures post for the full taxonomy.
• The visitor's system clock is wrong (rare but possible — happens after a CMOS battery dies).

How to fix it (as the site owner): renew the cert. Then make sure this doesn't happen again — external monitoring is the answer; your renewal automation is not enough on its own because it can fail silently.

If you want to confirm the expiration date from outside before you do anything, the free checker reads it off the live handshake in a couple of seconds.

NET::ERR_CERT_COMMON_NAME_INVALID / SSL_ERROR_BAD_CERT_DOMAIN

What it means: the cert is valid but it doesn't list the hostname the user typed in its Subject Alternative Name (SAN) list.

Common causes:

• You issued a cert for example.com but the user typed www.example.com (or vice versa).
• You have a wildcard cert *.example.com and the user is hitting the apex example.com — wildcards don't cover the apex by themselves; see our wildcard vs SAN post.
• You're hitting an IP address directly and the cert is for a hostname.
• DNS is misconfigured and pointing to a server that has a cert for a different site.

How to fix it: re-issue the cert with the right hostnames in the SAN list, or update DNS to point at the right host, or both. If you genuinely need to support both example.com and www.example.com, the cert must list both as SANs (or include a wildcard plus the apex explicitly).

NET::ERR_CERT_REVOKED

What it means: the CA actively revoked this cert (usually because a key was compromised or the cert was mis-issued).

Common causes: a previous private key leak that got reported to the CA, or a CA-initiated revocation after an audit issue. Rare in practice — most browsers don't strictly enforce revocation, but the ones that do will surface this.

How to fix it: get a new cert. The revoked one isn't coming back.

NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM

What it means: the cert uses a signature algorithm (SHA-1, MD5) that's no longer considered secure.

Common causes: ancient cert hasn't been renewed in years. Internal CA that's still issuing SHA-1.

How to fix it: re-issue with SHA-256. If you're seeing this on a public CA cert, the CA shouldn't even be capable of issuing one — this is almost always a sign that the cert is very old or that an internal CA is involved.

NET::ERR_CERT_SYMANTEC_LEGACY

What it means: the cert was issued by the legacy Symantec CA infrastructure, which Google distrusted as a remediation outcome in 2018.

How to fix it: re-issue with any non-Symantec-lineage CA. Let's Encrypt, DigiCert, Sectigo, anyone. This error is mostly historical at this point but occasionally surfaces on long-unmaintained sites.

NET::ERR_SSL_VERSION_OR_CIPHER_MISMATCH

What it means: the cert is probably fine, but the protocol version or cipher suite the server is offering doesn't overlap with what the browser will accept.

Common causes: server is configured to only accept TLS 1.0 or 1.1 (which modern browsers refuse to use — see SSL vs TLS), or only offers very old cipher suites that have been removed from modern clients.

How to fix it: update the server's TLS config to support TLS 1.2 + 1.3 and modern cipher suites. Mozilla's SSL Configuration Generator generates known-good configs for nginx, apache, and others.

"Should I click Advanced and proceed anyway?"

The answer depends on which error you're seeing and whose site it is.

• AUTHORITY_INVALID on a corporate intranet site that's supposed to be signed by an internal CA, and you're on the corporate network — yes, fine.
• AUTHORITY_INVALID on a public site like a bank, an email provider, anything with a login form — no, never. Either the cert is misconfigured (close the tab and try later) or an attacker is intercepting your connection (close the tab and try later, but from a different network).
• DATE_INVALID on a site you trust that just expired today — clicking through is annoying but usually fine. The connection is still encrypted; the only issue is the cert can't be cryptographically verified as fresh. Don't enter passwords from this state, though.
• COMMON_NAME_INVALID on a site you trust — usually safe to proceed (it's almost always a misconfig), but consider whether you got there via a clean URL or a click from somewhere suspicious.
• REVOKED on any site — don't proceed. Revocation means something bad is known about this cert specifically.

The rule of thumb: if the warning is from a misconfiguration, it's usually safe to proceed but worth reporting to the site owner. If you can't tell whether it's a misconfiguration or an attack, assume the worst and try again later from a different network.

If you're the site owner

The whole genre of these errors has the same underlying cause: someone shipped a cert that the browser couldn't validate. The fix is always "fix the cert" — through some combination of renewing, re-issuing with the right hostnames, fixing the chain, or moving to a CA that doesn't trigger weak-signature complaints.

The way to make sure you're not in this situation in the first place is:

1. Use a public CA (Let's Encrypt, or any commercial one). Don't self-sign anything that real visitors hit.
2. Automate renewal. Manual renewal will fail eventually.
3. Externally monitor the cert. Automation will fail silently sometimes; external monitoring catches what your renewal logs don't.

You can verify any site's cert configuration right now from outside with our free checker — it'll show you the issuer, the expiration date, and the SAN list, which between them resolves about 90% of these errors. For ongoing monitoring that emails you before the cert expires (instead of after, when you find out via "your connection is not private" in your support inbox), sign up here.

Either way: the warning page exists for good reasons, but the right response is almost always to fix the underlying cert, not to teach your visitors to click through it.