Fix "Your Connection Is Not Private" in Chrome

Chrome shows "Your connection is not private" with a red shield and a "Back to safety" button when the browser refuses to trust the SSL certificate on the site you're trying to reach. This guide covers what the warning means, the most common causes, and how to fix it - whether you're the site visitor or the site owner.

What Chrome is checking

Before showing you a website over HTTPS, Chrome checks three things about the certificate the server presents:

• Is the certificate still valid? Both the start date (notBefore) and end date (notAfter) must include "now."
• Does the certificate match the hostname? The domain in the address bar must appear on the certificate's Subject Alternative Name list.
• Is the certificate's issuer trusted? The certificate must chain up to a Certificate Authority in Chrome's trust store.

If any of these fail, Chrome shows "Your connection is not private." The specific error code underneath (visible if you click "Advanced") tells you which check failed.

The error codes you'll see

• NET::ERR_CERT_DATE_INVALID - the certificate has expired (or is not yet valid).
• NET::ERR_CERT_COMMON_NAME_INVALID - the certificate doesn't match the hostname.
• NET::ERR_CERT_AUTHORITY_INVALID - the certificate is signed by an issuer Chrome doesn't trust (often a self-signed cert).
• NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM - the certificate uses an outdated signing algorithm (SHA-1 in modern Chrome).
• NET::ERR_SSL_VERSION_OR_CIPHER_MISMATCH - the server only supports TLS versions or ciphers Chrome refuses to negotiate.
• NET::ERR_CERT_REVOKED - the issuing CA revoked the certificate.

If you're a visitor seeing this warning

The safe answer is to leave the site. The warning exists because trust is genuinely broken - entering passwords or payment information is risky.

Three exceptions where it's reasonable to investigate further:

• The site is your own. Use the fixes for site owners below.
• The site is an internal tool with a known self-signed certificate. Your IT team can add the certificate to your trust store; don't just click through.
• Your system clock is wrong. A wrong clock makes valid certificates look expired or not-yet-valid. Check your system time.

If you own the site and need to fix it

For NET::ERR_CERT_DATE_INVALID (expired)

You need a new certificate. The fastest path is a free Let's Encrypt certificate via Beacon:

For NET::ERR_CERT_COMMON_NAME_INVALID (hostname mismatch)

Your certificate doesn't cover the hostname visitors are using. Either issue a new certificate that includes the hostname in its SAN list, or configure your server to use the right certificate for the right hostname (SNI). Common cases:

• A wildcard *.example.com doesn't cover api.eu.example.com (wildcards only cover one level deep).
• Multiple sites on one IP with SNI misconfigured - the wrong certificate is being served for one of them.
• A new subdomain launched without a matching certificate.

For NET::ERR_CERT_AUTHORITY_INVALID (untrusted issuer)

Your certificate is signed by a CA Chrome doesn't trust. Almost always one of: a self-signed certificate, an internal CA without the root distributed to client trust stores, or a CA whose root has been distrusted by Chrome as part of routine root lifecycle policy.

Check which root your certificate chains to

This is the most common live cause of this error in 2026. Chrome periodically drops trust in older CA roots on a published constraint date; if your certificate chains to one of them, it fails regardless of how valid the rest of the certificate is. Check with:

echo | openssl s_client -showcerts -servername example.com -connect example.com:443 2>/dev/null \
  | grep -E "(s:|i:)"

If the issuer is a legacy root your CA has migrated away from, ask for reissuance from their current hierarchy. The deep dive on the real causes of NET::ERR_CERT_AUTHORITY_INVALID in 2026 covers the specific distrusted roots and current replacements per CA.

A separate risk: CA-side compliance revocation

Chrome will eventually reject certificates that mix serverAuth and clientAuth Extended Key Usages, but not until March 15, 2027 - this isn't live browser behavior today. The real near-term risk is different: some CAs have written an earlier internal deadline into their own compliance policy, and if their issuance systems fall out of sync with that policy, they're contractually required to force-revoke every affected certificate on short notice, independent of anything Chrome itself enforces. This isn't hypothetical - it happened to tens of thousands of certificates in July 2026. Read about the incident and how to check whether you're exposed.

For self-signed or internal-CA cases

Use a publicly-trusted CA - Let's Encrypt, DigiCert, Sectigo, etc. For an urgent replacement, Beacon issues free Let's Encrypt certificates in about 10 minutes.

For NET::ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Your server is too restrictive on TLS version or cipher suites. Modern Chrome requires TLS 1.2 minimum (TLS 1.3 preferred) and rejects deprecated ciphers. The Mozilla SSL Configuration Generator produces ready-to-paste configurations for most web servers.

Make this the last warning visitors see

Browser warnings happen when monitoring catches problems too late - or doesn't catch them at all. Continuous monitoring catches the certificate problems before users see them.

Related reading

• My SSL certificate expired - how to fix it now
• How to fix an SSL certificate outage
• Fix 'Warning: Potential Security Risk Ahead' in Firefox