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:
Need a working certificate right now?
Beacon issues free 90-day Let's Encrypt certificates with a guided DNS-validation flow. No account, no command-line tools, no ACME client to install - just a domain you control. Most people get a working certificate in under 10 minutes.
Get a free certificate from BeaconFor 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.comdoesn't coverapi.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 (rarely) a CA that's been distrusted by Chrome. The fix is to use a publicly-trusted CA - Let's Encrypt, DigiCert, Sectigo, etc.
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.
Stop this from happening again
TLS Radar continuously monitors every certificate across your domains and alerts you weeks before anything expires, and also catches the silent failure modes (chain breaks, weak ciphers, hostname mismatches) that expiry-only monitoring misses. Built for solo developers monitoring a handful of sites and for enterprise teams managing thousands of certificates across multiple environments.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.