Your connection is not private Attackers might be trying to steal your information from example.com (for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID
NET::ERR_CERT_AUTHORITY_INVALID means the certificate the site presented does not chain up to a certificate authority your browser trusts. The traffic is encrypted, but the browser cannot verify who it is encrypted to.
Before any fix: this is the one browser error where the wrong response has real consequences. The same message appears for a harmless internal certificate and for an active interception attack. Read the issuer first.
Is This You or the Site?
Step 1: Find out who issued the certificate
This single fact resolves almost every case.
In the browser: click Not secure in the address bar, then the certificate icon, then read Issued by.
From a terminal:
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates
Then interpret it:
| Issued by | Meaning | Action |
|---|---|---|
| Your employer's security product (Zscaler, Netskope, Palo Alto, Forcepoint) | Corporate TLS inspection | Benign. IT needs to deploy the root to this machine. |
| Your own internal CA | Private PKI, root not installed here | Benign. Install the root, or ask IT to. |
| Your antivirus (Kaspersky, ESET, Avast, Bitdefender) | Local HTTPS scanning | Benign but worth reviewing. See below. |
| The site itself - issuer equals subject | Self-signed certificate | Site-owner problem. |
| A real CA, but the chain is incomplete | Missing intermediate | Site-owner problem. |
| Something you do not recognise, on a public network | Possible interception | Stop. Do not proceed. |
Step 2: Check whether it fails for everyone
Load the site from mobile data with Wi-Fi off. If the certificate is fine there and broken on your current network, something on that network is intercepting traffic - which is expected on a corporate laptop and a serious warning sign in a hotel or café.
Our SSL/TLS checker reports the certificate as seen from outside your network, so a mismatch between what it reports and what your browser shows tells you the substitution is happening locally.
Step 3: When to stop rather than fix
Do not proceed if any of these are true:
- You do not recognise the issuer and you are not on a managed corporate device
- You are on public Wi-Fi, a hotel network, or a conference network
- The site is a bank, a payment provider, or anything holding credentials you care about
- The certificate details do not match what certificate transparency logs show has actually been issued for that domain
Comparing against CT logs is the strongest check available to a visitor. Every certificate a public CA issues is logged publicly, so a certificate that appears in your browser but nowhere in the logs was not issued by a public CA for that site.
Visitor-Side Fixes
Corporate TLS inspection
Nothing is wrong with the site. Your organization's proxy reissues certificates, and its root CA is missing from this machine's trust store. The fix belongs to IT - they deploy the root by Group Policy or MDM. If you have been told to install it yourself, and you have confirmed with IT that the CA is genuinely theirs:
certlm.msc → Trusted Root Certification Authorities → Certificates
→ right-click → All Tasks → Import
Understand what you are doing: a root certificate can vouch for any site on the internet. Install one only when you know who operates it.
Antivirus HTTPS scanning
Security suites that scan HTTPS do the same substitution locally. Temporarily disabling the "HTTPS scanning" or "SSL/TLS filtering" feature and reloading confirms the diagnosis. If that is the cause, reinstalling or repairing the product usually restores its root properly - leaving HTTPS scanning permanently off is a real tradeoff, so make it deliberately.
Check the system clock
A clock that is wrong by months makes valid certificates appear untrusted. Set it correctly:
w32tm /resync
Set it to the correct time. Never move the clock to a wrong date to make a warning disappear - that silently disables expiry checking for every site.
What not to do
Do not use flags or settings that disable certificate validation, and do not add a permanent exception for a certificate whose issuer you could not identify. Both remove protection well beyond the single site you were trying to reach.
Site-Owner Fixes
1. Serve the full chain
This is the most common cause by a distance. Your server must send the leaf certificate and the intermediate certificates. Browsers sometimes repair an incomplete chain from cache, which is why a site can work for you and fail for others.
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | grep -E "verify (error|return code)"
verify error:num=20:unable to get local issuer certificate means the intermediate is missing. Concatenate it into the certificate file your server points at - your CA supplies a "full chain" or "bundle" file for exactly this.
For nginx, ssl_certificate must point at the combined leaf-plus-intermediate file, not the leaf alone. For Apache, modern versions read the chain from SSLCertificateFile.
2. Replace a self-signed certificate
If the issuer equals the subject, the certificate signed itself. That is fine for a lab and unacceptable for anything a browser must trust automatically. Issue a real certificate - Let's Encrypt is free and automatable.
3. Check what you actually deployed
Decode the certificate the server is serving and confirm it is the one you meant to install, with the right issuer and validity dates. Our X.509 certificate decoder reads the fetched certificate and flags chain problems.
Verify the Fix
# Should end with: Verify return code: 0 (ok)
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | grep "Verify return code"
Then load the site in a fresh browser profile - not just a reload, since browsers cache certificate decisions - and confirm the padlock appears. Check from a device that has never visited the site before, which is the only way to be sure you fixed the chain rather than benefiting from a cached intermediate.
Prevention
- Deploy the full chain file every time you renew, not just the leaf. Chain regressions at renewal are the standard cause of this error returning.
- Monitor expiry and chain validity from outside your network, so you learn about a problem before your visitors do.
- On managed fleets, push the inspection proxy's root CA through Group Policy or MDM so no user ever sees this warning and learns to click past it.
- Train staff to read the issuer rather than to dismiss the dialog. A workforce conditioned to click through this warning will click through the one that matters.
- Automate renewal. Most chain problems are introduced by hand during a manual renewal at short notice.