Skip to content

Test your website now

Free, no card. We read only public pages.

Run free audit →

HTTPS and TLS

Why does Chrome say your connection is not private?

The warning means the browser could not verify the site's certificate. What each NET::ERR_CERT code means, what visitors can do, and how owners fix it.

Chrome shows “Your connection is not private” when it cannot verify the site's TLS certificate: it has expired, is issued for a different domain, is missing an intermediate certificate, or is not trusted. Occasionally the visitor's clock or network is the cause. Site owners fix it by renewing or reissuing the certificate and serving the full chain.

Published · Last updated

By Michal Měřínský. Audit methodology.

What the warning means

When you open an HTTPS site, the server presents a certificate proving it is the domain you asked for. If the browser cannot confirm that proof, it stops and warns you, because it cannot rule out that someone is intercepting the connection. The warning does not prove an attack. It says the proof is missing or wrong.

The error code under the message tells you which part failed:

  • NET::ERR_CERT_DATE_INVALID - the certificate has expired, or the device's date is wrong.
  • NET::ERR_CERT_COMMON_NAME_INVALID - the certificate is for a different name, such as example.com but not www.example.com.
  • NET::ERR_CERT_AUTHORITY_INVALID - the certificate is self-signed, from an untrusted issuer, or the chain is incomplete.

If you are a visitor

  • Check your device's date and time. A wrong clock makes valid certificates look expired.
  • If you are on hotel, airport or café Wi-Fi, open any plain website first. Captive portals intercept HTTPS until you accept their terms.
  • Try another network or device. If the error disappears, the problem is local, such as antivirus software inspecting HTTPS.
  • Do not continue to a site that asks for a password or payment while the warning is showing.

Why your own site shows it, most likely first

  • The certificate expired because automatic renewal failed, often after a DNS or server change.
  • The certificate does not cover the name visitors use. www, the bare domain and subdomains each need to be on the certificate.
  • The server sends only the site certificate and not the intermediate certificate, so some browsers and devices cannot build the chain.
  • A self-signed or development certificate reached production.
  • A CDN or load balancer serves its own certificate for a domain it has not been configured for.

How to fix it

Inspect what the server actually presents:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
  • Expired: renew, then find out why automatic renewal failed so it does not repeat in 90 days.
  • Wrong name: reissue the certificate with every hostname visitors use, or redirect the uncovered name in a way that does not need a certificate you lack.
  • Incomplete chain: configure the server to send the full chain file, not only the leaf certificate.
  • On managed platforms such as Vercel, Netlify or Cloudflare, check that the domain shows as verified and the certificate as issued. Pending DNS validation is the usual blocker.

Testing only in your own browser is not enough. Browsers cache intermediate certificates, so an incomplete chain can work for you and fail for a new visitor or a phone.

Crawlers that cannot complete a TLS handshake cannot fetch the page, so a broken certificate makes the site unreachable to them as well. The larger cost is human: almost nobody clicks through a full-page security warning, so traffic and sales stop until the certificate is fixed.

What a scan can and cannot tell you

WebAuditOS checks that the certificate is valid and trusted with a complete chain, warns when it is close to expiry, and checks that the site is served over HTTPS at all. An expiry warning in advance is the cheapest way to avoid this error entirely.

A scan sees the certificate served to its own connection. A CDN that serves different certificates by region, or a device with an outdated trust store, can behave differently.

A valid certificate today says nothing about renewal. Expiry warnings exist because renewal is where most of these outages start.

Short answers

Is it safe to proceed anyway? On a site where you enter nothing, the risk is low. On a site asking for a password or payment, no.

Why does it work on my laptop but not on my phone? Usually a missing intermediate certificate that your laptop had cached.

Does a free certificate trigger the warning? No. Let's Encrypt certificates are trusted by all major browsers.

How often do certificates need renewing? Let's Encrypt certificates last 90 days, which is why automatic renewal matters.

In the product

The checks this maps to

Every check named here runs on every scan, on every plan - what a plan changes is how many pages are crawled, how long the history is kept and what you can do with the result. These are the ids the findings carry, so you can match a line in a report to the explanation above.