Fix "Your Connection Is Not Private" in Chrome
Chrome shows 'Your connection is not private' when it refuses to trust the SSL certificate a site presents. Before loading an HTTPS page, Chrome checks three things: that the certificate is within its validity dates, that it matches the hostname, and that it chains to a trusted CA - and the error code under 'Advanced' tells you which check failed. If you are a visitor, the safe move is to leave (unless it is your own site, a known internal tool, or your clock is wrong). If you own the site, each NET::ERR_CERT_* code maps to a specific fix.
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 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.
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, risky EKUs, and distrust events - that keep a site from opening in every browser. Built for solo developers monitoring a handful of sites and for enterprise teams managing thousands of certificates across multiple environments.
Related reading
Frequently asked questions
- What does 'Your connection is not private' mean in Chrome?
- It means Chrome would not trust the SSL certificate the site presented, so it blocked the page. Chrome checks that the certificate is within its validity dates, matches the hostname, and chains to a trusted certificate authority. If any check fails, Chrome shows this warning and an error code (under 'Advanced') identifying which one.
- How do I fix NET::ERR_CERT_DATE_INVALID?
- That code means the certificate has expired (or is not yet valid). If you own the site, issue a new certificate - a free Let's Encrypt certificate takes about ten minutes. If you are a visitor, first check that your device's clock is correct, because a wrong clock makes valid certificates look expired.
- Should I click through Chrome's 'not private' warning?
- As a visitor, no - the warning means trust is genuinely broken, so do not enter passwords or payment details. The reasonable exceptions are when it is your own site (fix the certificate), a known internal tool with a self-signed certificate (have IT add it to the trust store), or your system clock is wrong.
- Why does the site work in another browser but not Chrome?
- Chrome keeps its own trust store, so it can distrust the CA root your certificate chains to while other browsers still trust it - producing NET::ERR_CERT_AUTHORITY_INVALID in Chrome only. The fix is to reissue from a root Chrome currently trusts and install the full chain.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.