"Your connection is not private": what it means and how to fix it

"Your connection is not private" is the full-page warning Chrome shows when a site's certificate fails its checks: the certificate has expired, it does not cover the name in the address bar, or it was not issued by an authority the browser trusts. The browser stops before loading anything, because it cannot prove it is talking to the real site. The error code under the message, such as NET::ERR_CERT_DATE_INVALID, tells you which check failed. This guide starts with the quick fix for visitors, then goes through each code and the fix on the server. How certificates earn that trust in the first place is explained in what an SSL certificate is and how HTTPS works.

Quick answer

• Visitor: check your device's date and time, reload, and try another network. If the site is one you use often and the warning appears everywhere, the site's certificate is broken; do not click through on a page that asks for passwords or payment.
• Site owner: read the code. ERR_CERT_DATE_INVALID is an expired certificate, ERR_CERT_COMMON_NAME_INVALID a missing name, ERR_CERT_AUTHORITY_INVALID a self-signed certificate or a missing intermediate.
• Fix it at the source: renew and automate, add every host name to the certificate, and install the full chain (fullchain.pem), then reload the web server.
• A public certificate issued today lasts at most 200 days, so renewal has to be automatic.
• Confirm with the SSL checker from outside your network.

What the warning means

Before a browser shows an HTTPS page, it checks the site's certificate three ways: that a trusted certificate authority signed it (through a chain of intermediates), that it covers the exact host name you typed, and that today falls between its "valid from" and "valid to" dates. If any check fails, you get this page instead of the site.

Each browser words it differently:

The warning is about identity, not about the site being hacked. It means the browser cannot confirm who is on the other end. On a real site that usually means a configuration mistake; on a hostile network it can mean someone is intercepting traffic, and the browser cannot tell the two apart. That is why it blocks both.

If the handshake never gets as far as a certificate, the browser shows a different page, "This site can't provide a secure connection". That one is covered in fixing ERR_SSL_PROTOCOL_ERROR.

If you're a visitor: the quick fix

1. Check the date and time on your device and set them to automatic. A clock that is wrong by days makes every valid certificate look expired or not yet valid. This is the most common cause when the warning appears on many sites at once.
2. Reload, then try another network. Hotel, café and airport Wi-Fi often intercept the first HTTPS request to show a login page. Open any http:// address to bring up the login page, sign in, then retry.
3. Turn off HTTPS scanning in antivirus software, and pause VPNs or proxies. They replace certificates with their own and sometimes get it wrong.
4. Update your browser and operating system. Very old devices lack current root certificates and reject certificates that newer devices accept.
5. If it only happens on one site, on every device and network, the site is at fault. Let the owner know, and wait.

Should you click "Advanced" and proceed? Only if you know why the warning appears and nothing sensitive is involved, such as a router's admin page on your own network. Never on a site where you log in or pay. On sites that use HSTS, the browser removes the "Proceed" link entirely, by design.

If you own the site: read the error code

The code tells you the fix. Start with a test from outside, so your own browser's cache does not hide anything:

getReport's page fetch validates certificates strictly, like a phone or an API client would. If your certificate is expired, for the wrong name or untrusted, the report cannot load the page over HTTPS and stops with "We could not reach that site" (if you typed the address without https://, it first retries over http://). When the certificate validates, these findings show its state:

Then use OpenSSL to see what the server sends, and for which name:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

That prints the names the certificate covers, who issued it and its dates.

NET::ERR_CERT_DATE_INVALID: the certificate has expired

The certificate's "not after" date has passed (or, rarely, its "not before" date is in the future). Every visitor sees the warning at the same moment, which is why it is the most visible of these failures.

Fix it now, then make sure it never happens again:

• Let's Encrypt with certbot: sudo certbot renew, then reload the web server. If renewal fails, the output says why: usually port 80 blocked, /.well-known/acme-challenge/ redirected or blocked, or DNS pointing elsewhere.
• Hosting panel: re-run AutoSSL or the "Let's Encrypt" switch for the domain.
• Paid certificate: buy the renewal, install the new certificate with its intermediate, reload.

Certificates are getting shorter by design: public certificates issued from 15 March 2026 last at most 200 days under the CA/Browser Forum rules, falling to 100 days in 2027 and 47 days in 2029. Let's Encrypt stopped sending expiry reminder emails in June 2025. Renewal has to be automatic and monitored; how to set that up is in certificate expiry: automate renewal, then monitor it.

If the certificate on the server is new and visitors still see an old date, the web server was not reloaded after renewal. nginx and Apache keep the old certificate in memory until you run systemctl reload.

NET::ERR_CERT_COMMON_NAME_INVALID: the certificate is for another name

The certificate is valid, but not for the host name in the address bar. Browsers only look at the certificate's Subject Alternative Name list (Chrome stopped reading the old Common Name field in 2017), so the exact name must be there.

Typical causes:

• The certificate covers example.com but not www.example.com, or the reverse. Both need to be on it, because the redirect from one to the other only happens after the handshake.
• A new subdomain falls through to the server's default site and gets that site's certificate.
• A wildcard *.example.com is used for example.com itself or for a.b.example.com. A wildcard covers exactly one level.
• DNS points to an old server or a shared host's default page.

Fix it by issuing a certificate that lists every name. With certbot: sudo certbot --nginx -d example.com -d www.example.com. On hosting panels, add the www alias or subdomain, then reissue.

NET::ERR_CERT_AUTHORITY_INVALID: the issuer is not trusted

The browser could not build a chain from the certificate to a root it trusts. Three causes cover almost every case:

• Self-signed certificate: common on new servers, control panels and appliances. Replace it with a free certificate from Let's Encrypt or your host.
• Missing intermediate certificate: the server sends only its own certificate. Desktop Chrome often fills the gap, while phones, curl and other servers do not, so some visitors see the warning and others do not. Install the full chain; see certificate chain errors and intermediate certificates.
• A certificate authority browsers stopped trusting: Chrome, for example, stopped trusting Entrust certificates issued after 11 November 2024. If your certificate comes from a distrusted authority, replace it with one from another CA.

A Cloudflare Origin CA certificate on a server that visitors reach directly also shows this error: it is trusted by Cloudflare only, not by browsers.

Other codes you may see

• NET::ERR_CERT_REVOKED: the authority revoked the certificate, for example after a key leak or a mis-issuance. Get a new one; the old one cannot be revived.
• NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM: a very old certificate signed with SHA-1. Replace it.
• NET::ERR_CERT_INVALID: Chrome could not read the certificate or it breaks the format rules. Reissue it from a public CA.
• A warning with no "Proceed" link: the site uses HSTS, covered below. The cause is still one of the codes above.

HSTS removes the way around it

If your site sends Strict-Transport-Security, browsers that have seen the header will not let visitors click past a certificate warning on your domain. That is the point of HSTS, and it means a certificate failure becomes a complete outage for returning visitors. Keep HSTS, but make renewal automatic and monitored first. HSTS: enabling it safely covers the order to do it in.

How to verify the fix

1. The openssl command above shows the right names, an issuer that is a public CA and a "not after" date in the future.
2. openssl s_client -connect example.com:443 -servername example.com ends with Verify return code: 0 (ok).
3. Open the site on a desktop and on an Android phone over mobile data. Phones catch missing intermediates that desktops hide.
4. Run the SSL checker: the chain finding passes and the certificate has 30 or more days left.
5. Check www and every subdomain visitors use, not only the main name.

Common mistakes

• Renewing the certificate but not reloading the server. The new file sits on disk while the old one keeps being served.
• Fixing example.com and forgetting www.example.com, or a subdomain used only in emails or ads.
• Testing only in your own desktop browser, which remembers intermediates and may have visited the site before.
• Installing cert.pem instead of fullchain.pem.
• Turning on HSTS before renewal is automatic. A lapse then locks every returning visitor out.

Questions people ask

How do I fix "Your connection is not private"?

Find out whose side the problem is on. If the warning appears on many sites, fix your device: set the date and time to automatic, sign in to the Wi-Fi's login page, and turn off HTTPS scanning in antivirus software. If it appears on one site for everyone, the site owner must fix the certificate: renew it if expired, add the missing host name, or install the full chain, then reload the server.

Is it safe to proceed when it says "Your connection is not private"?

Usually not. The browser cannot confirm it is talking to the real site, so anything you send, including passwords and card numbers, could reach someone else. Proceeding is reasonable only when you know the cause and nothing sensitive is involved, such as a device on your own network with a self-signed certificate. On sites with HSTS the browser does not offer the option at all.

Why does "Your connection is not private" appear on every website?

When every site shows it, the cause is your device or network, not the sites. The usual culprit is a wrong date and time, which makes valid certificates look expired. Others are a public Wi-Fi login page intercepting HTTPS, antivirus or a VPN that inspects encrypted traffic, or a device so old it lacks current root certificates. Fix the clock first, then test on another network.

What does NET::ERR_CERT_COMMON_NAME_INVALID mean?

It means the certificate is valid but was issued for a different name than the one in the address bar. Most often it covers example.com but not www.example.com, or a new subdomain gets the server's default certificate. Browsers only read the certificate's Subject Alternative Name list, so the site owner must reissue the certificate with every host name visitors use, then reload the server.

Why do some visitors see the warning and others don't?

Usually because the server does not send its intermediate certificate. Desktop Chrome, Edge and Safari can fetch or remember it, so they show the padlock, while Android phones, older devices, apps and other servers cannot build the chain and show the warning. Other causes are a wrong clock on one device or security software intercepting HTTPS on one network. Install the full chain file to fix the first case.