Writing

NET::ERR_CERT_AUTHORITY_INVALID

Published 15 September 2026 · Updated 22 September 2026

The screen says "Your connection is not private", and this code sits underneath it. Spelled out it reads certificate authority invalid, and the middle word is the one that matters: the fault is not the certificate itself but the authority behind it, which Chrome cannot trace back to a root it trusts. The instinct is to assume the site is broken. More often than not, something on your machine or network is rewriting the certificate on its way to you, and there is a ten-second check that tells you which.

The ten-second check: read the issuer

Click the warning in the address bar, open the certificate details, and look at who issued it.

• If the issuer is a name you recognise as security software or your employer (Zscaler, Netskope, Palo Alto, Fortinet, Sophos, ESET, Kaspersky, Avast, BitDefender, or your own company's name), the connection is being intercepted locally. Go to cause 1.
• If the issuer is the site's own name, it is a self-signed certificate. Cause 2.
• If the issuer is a real CA you have heard of, such as Let's Encrypt, DigiCert or Sectigo, the certificate is probably genuine and the chain is incomplete. Cause 3.

That one field narrows it to a single cause almost every time, and it is the step most advice leaves out in favour of telling you to clear your cache.

1. On every website? Something is intercepting HTTPS

This is the most common cause on a managed laptop, and it is not necessarily a fault. Corporate proxies and antivirus "web shields" work by terminating TLS, inspecting the plaintext, and re-encrypting it with their own certificate. For that to work invisibly, their root certificate has to be installed in your trust store. When it is missing, expired, or the software was installed without it, every HTTPS site starts failing this way.

The tells:

• The issuer is the security product or your employer.
• Many sites fail, not one.
• It works on your phone, on mobile data, or on a personal machine.

The fix belongs to whoever manages the machine: install or renew the proxy's root certificate. Do not work around it by clicking through the warning: the whole point of the interception is that someone is reading the traffic, and you want that to be the party you think it is.

2. The certificate is self-signed

Common on internal tooling, NAS boxes, printers, routers, development servers and anything with a web interface on your own network. Nobody vouched for the certificate but the server itself, so there is no authority to validate.

For a device on your own network this is expected rather than alarming. Add its certificate to your trust store if you use it regularly, or run an internal CA if there are many. On a public site, a self-signed certificate means something is wrong: that is not a configuration anyone ships deliberately.

3. The chain is incomplete

The server holds a perfectly valid certificate but is not sending the intermediate that connects it to a trusted root. Browsers often paper over this by fetching the missing piece themselves, which is why the site can work for some people and fail for others on the same day.

The giveaway is that it fails in strict clients while browsers vary: curl, API clients and mobile apps reject it outright. If you have also seen unable to get local issuer certificate from the command line against the same host, this is your cause, and that article covers the two opposite situations it can mean.

4. The certificate came from a CA that is no longer trusted

Browsers do remove authorities. Symantec's roots were distrusted over 2017–2018, and several smaller CAs have gone the same way since. A certificate issued by one of them will be rejected however correctly it is installed.

The tell is that the issuer is a real CA name, the chain is complete, and it still fails: with different browsers disagreeing depending on how far through the removal schedule each one is. The only fix is reissuing from a current authority.

5. An internal CA that this machine does not know about

Bigger organisations run their own certificate authority for internal services. It works on a domain-joined machine that received the root through policy, and fails on a contractor's laptop, a personal device, or a freshly imaged build that has not picked up the policy yet.

Same shape as cause 1, different reason: the certificate is legitimate, the trust anchor simply is not present here.

What not to do

• Do not click "Proceed anyway" out of habit. On a site where you type a password it is the one warning worth respecting. If a proxy is intercepting, proceeding hands your credentials to it.
• Do not use --ignore-certificate-errors to make a browser quiet. It disables validation for everything, not this one site.
• Do not start with the cache and the clock. A wrong clock produces ERR_CERT_DATE_INVALID, which is a different message: if Chrome says authority, the clock is not your problem.

The related messages, and what each one means

• ERR_CERT_AUTHORITY_INVALID: cannot reach a trusted root. This page.
• ERR_CERT_COMMON_NAME_INVALID: the certificate is trusted but is for a different hostname.
• ERR_CERT_DATE_INVALID: expired, not yet valid, or your clock is wrong.
• ERR_CERT_REVOKED: the CA withdrew it. Treat as serious.
• ERR_SSL_PROTOCOL_ERROR: the handshake failed before certificates mattered. See peer failed to perform TLS handshake.

Node, Python and Java keep trust stores of their own, separate from the system's, so the same interception that a browser accepts will break them. That is covered in self signed certificate in certificate chain.

A direct IP is a different identity question, not an authority workaround. Public CAs can now issue an IP address SSL certificate for a validated public IPv4 or IPv6 address, but private and reserved addresses still need a private CA or an internal DNS name.