You click a link, expect a familiar page, and instead Chrome fills the screen with a stark warning: "Your connection is not private." Below it sits a cryptic code like NET::ERR_CERT_AUTHORITY_INVALID. Whether you are a visitor trying to reach a site or the owner watching traffic evaporate, the error is almost always fixable in minutes — once you know which of a handful of causes is behind it.
The warning is not malware, and it does not mean you have been hacked. It means your browser tried to establish an encrypted HTTPS connection and could not verify the website's SSL/TLS certificate. Because the certificate is the site's identity document, the browser refuses to load the page rather than risk sending your data to an impostor.
This guide explains what triggers the warning, how visitors can clear it in seven quick steps, and how site owners can diagnose and permanently fix it — plus why an industry-wide change to certificate lifetimes means you will see this error more often from 2026 onward.
What the warning actually means
More than 95% of pages loaded in Chrome are served over HTTPS, according to Google's Transparency Report. HTTPS does two jobs: it encrypts traffic, and it proves the server really is the one named in the address bar. That proof comes from the TLS certificate, which your browser validates on every single connection. Three checks must all pass:
- Trust — the certificate was issued by a certificate authority (CA) your device trusts.
- Validity — today's date falls inside the certificate's validity window.
- Identity — the domain in the address bar matches a name listed in the certificate.
If any check fails, the browser blocks the page and shows the interstitial instead. Encryption without verified identity is worthless — an attacker on public Wi‑Fi could otherwise silently decrypt everything you send.
The same error in every browser
Each browser words the warning differently, but the underlying certificate problem is identical.
| Browser | Warning text | Typical error codes |
|---|---|---|
| Chrome | "Your connection is not private" |
NET::ERR_CERT_AUTHORITY_INVALID, NET::ERR_CERT_DATE_INVALID
|
| Edge | "Your connection isn't private" | Same NET::ERR_CERT_* codes as Chrome |
| Firefox | "Warning: Potential Security Risk Ahead" |
SEC_ERROR_EXPIRED_CERTIFICATE, SEC_ERROR_UNKNOWN_ISSUER
|
| Safari | "This Connection Is Not Private" | Plain-language description, no code |
The code at the bottom of the warning is the most useful diagnostic you have:
-
NET::ERR_CERT_DATE_INVALID— the certificate has expired, or your device clock is wrong. -
NET::ERR_CERT_AUTHORITY_INVALID— the issuing CA is not trusted: a self-signed certificate, an incomplete certificate chain, or antivirus/proxy interception. -
NET::ERR_CERT_COMMON_NAME_INVALID— the certificate does not cover this exact domain, e.g. it coverswww.example.combut notexample.com. -
NET::ERR_CERT_REVOKED— the CA has withdrawn the certificate, often after a key compromise.
If you're a visitor: 7 fixes, fastest first
- Reload, then try an incognito/private window. This rules out a stale cached certificate or a misbehaving extension.
-
Check your device's date and time. A clock that is off by months makes every valid certificate look expired or not yet valid. Enable automatic time. This alone resolves a large share of
DATE_INVALIDerrors. -
On public Wi‑Fi, log in to the network first. Hotel and airport captive portals hijack requests until you authenticate, which breaks HTTPS. Visit a plain-HTTP site such as
http://neverssl.comto force the login page to appear. - Update your browser and operating system. Root certificates ship with OS and browser updates; very old devices no longer know the CAs modern sites use — the fate of many pre-7.1.1 Android phones after Let's Encrypt's root transition.
-
Temporarily disable HTTPS scanning in your antivirus. Security suites that inspect encrypted traffic re-sign it with their own certificate; when that goes wrong you get
AUTHORITY_INVALIDon every site. If the warning disappears, re-enable the feature and update or reconfigure the antivirus. - Clear your browser's cache and SSL state. In Chrome: Settings → Privacy and security → Clear browsing data.
- Still failing on one specific site — from every device and network? Then the problem is the site's, not yours. Do not click "Proceed"; on a login or payment page, that is exactly the risk this warning exists to prevent.
If it's your website: diagnose, fix, automate
First, see what the certificate actually says. From any terminal:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
Or skip the command line: a free FortifyNet scan reads your certificate, chain, and TLS configuration in about 60 seconds and tells you exactly what is wrong.
| Cause | Typical code | Permanent fix |
|---|---|---|
| Expired certificate | DATE_INVALID |
Renew now, then automate renewal (ACME/Certbot) |
| Incomplete chain (missing intermediate) |
AUTHORITY_INVALID — often only on mobile |
Serve the full chain (fullchain.pem, not cert.pem) |
| Name mismatch | COMMON_NAME_INVALID |
Reissue with SANs for apex + www; wildcard if needed |
| Self-signed certificate in production | AUTHORITY_INVALID |
Replace with a CA-issued certificate — Let's Encrypt is free |
| Revoked certificate | ERR_CERT_REVOKED |
Reissue with a new private key |
With Let's Encrypt securing hundreds of millions of sites at no cost, there is no reason to run production on a self-signed certificate. A typical setup on nginx:
sudo certbot --nginx -d example.com -d www.example.com
sudo certbot renew --dry-run
Certbot installs the certificate with its full chain and schedules automatic renewal — the single most effective protection against ever showing this warning.
Why this error is about to get more common
In April 2025 the CA/Browser Forum passed Ballot SC-081v3, a schedule that shrinks the maximum lifetime of public TLS certificates from 398 days to just 47 days by 2029, as DigiCert explains. Since 15 March 2026, no public CA may issue a certificate valid for longer than 200 days; in March 2027 the cap drops to 100 days, and in March 2029 to 47.
The practical consequence: a site renewing certificates by hand needs to do it at least twice a year today, and roughly eight times a year from 2029. Every manual step is a chance to forget — which is why automation plus expiry monitoring is now the baseline, not a nice-to-have.
FAQ
Is it ever safe to click "Proceed anyway"?
Only when you know exactly why the warning appears and no sensitive data is involved — for example, your own router's admin panel using a self-signed certificate. Never on banking, email, shopping, or any login page.
Why do I see the warning when nobody else does?
That points to a local cause: a wrong clock, aggressive antivirus, a captive portal, or an outdated OS that lacks modern root certificates. Work through visitor steps 1–6 above.
Why does my site show the error only on phones?
A classic sign of an incomplete certificate chain. Desktop browsers often cache missing intermediates; mobile browsers are stricter. Configure your server to send the full chain.
Does the warning affect SEO and traffic?
Directly: most visitors leave immediately, since the interstitial takes two deliberate clicks to bypass. Indirectly: HTTPS is a Google ranking signal, and prolonged certificate failures depress crawling and conversions alike.
Related guides
- SSL/TLS Certificate Security: The Complete Guide to Achieving A+ Rating
- Website Vulnerability Scanner: What It Checks and How to Read Results
Catch certificate problems before your visitors do
The warning your visitors see is the last symptom of a problem that was detectable weeks earlier. Run a free FortifyNet scan — 60 seconds, no signup — and get a plain-English report on your certificate expiry, chain, TLS configuration, security headers, DNS, and email authentication.
Originally published on the FortifyNet blog. FortifyNet is a free 60-second website security audit — I'm the founder, happy to answer questions in the comments.
Top comments (0)