NET::ERR_CERT_AUTHORITY_INVALID means the browser could not build a path from the site’s certificate to a root certificate it trusts. Three unrelated situations cause almost every case: a self-signed or private-CA certificate, a server that omits its intermediate certificate, or software on your device or network intercepting HTTPS. The issuer name on the certificate you received tells you which one.
This guide shows how to tell those cases apart in under a minute, then gives separate fixes for site owners (openssl diagnostics, fullchain configuration, Cloudflare and GoDaddy specifics, local development) and for visitors on Chrome, Edge, Android and Mac, including the case where the error appears on every website you open.
What NET::ERR_CERT_AUTHORITY_INVALID means
When a browser opens an HTTPS site, it validates the chain of trust: the site’s certificate must be signed by an intermediate certificate, which in turn must chain up to a root certificate in the browser’s trusted root store. Chrome ships its own store governed by the Chrome Root Program: if the chain does not terminate at a root on that list (or at a root your operating system or administrator added locally), the connection is flagged and ERR_CERT_AUTHORITY_INVALID is shown instead of the page. The role certificates play in TLS is covered in depth in the MDN Transport Layer Security documentation.
In Chrome the full page reads “Your connection is not private. Attackers might be trying to steal your information from example.com (for example, passwords, messages, or credit cards)”, with NET::ERR_CERT_AUTHORITY_INVALID printed underneath. Edge shows the same code under “Your connection isn’t private”, because it uses the same Chromium networking stack. The error is about trust in the issuer, not about encryption strength: the connection would be encrypted, but the browser cannot confirm who is on the other end.
How it differs from other certificate errors
| Browser message | What failed | Typical cause |
|---|---|---|
| NET::ERR_CERT_AUTHORITY_INVALID (Chrome, Edge) | Issuer is not trusted | Self-signed cert, missing intermediate, private CA, TLS interception |
| SEC_ERROR_UNKNOWN_ISSUER (Firefox) | Issuer is not trusted | Same causes; Firefox does not fetch missing intermediates on its own |
| MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT (Firefox) | Leaf is self-signed | Router, NAS, dev server, default certificate of a web server |
| “This Connection Is Not Private” (Safari) | Generic trust failure | Any of the above; open “Show Details” to see the issuer |
| NET::ERR_CERT_DATE_INVALID | Validity period | Expired certificate or wrong device clock |
| NET::ERR_CERT_COMMON_NAME_INVALID | Hostname | Certificate issued for a different domain |
| ERR_SSL_VERSION_OR_CIPHER_MISMATCH | Protocol negotiation | No shared TLS version or cipher suite |
Expired certificates are covered in how to fix an expired SSL certificate, and hostname errors in SSL certificate name mismatch.
Find out which case you have in one minute
Click “Not secure” (or the warning icon) in the address bar, open the certificate viewer, and read the Issued By field and the certification path. That single field sorts almost every case:
- Issuer equals the site name (Issued To and Issued By identical) — a self-signed certificate.
- Issuer is a public CA (Let’s Encrypt R10/R11, DigiCert, Sectigo, GlobalSign, GoDaddy) but the path stops at that intermediate — the server is not sending its chain, or your device lacks the root.
- Issuer is your antivirus, firewall or employer (Kaspersky, ESET, Avast, Fortinet, Zscaler, a company name) — traffic is being intercepted and re-signed.
- Issuer is “Cloudflare Origin Certificate” — you reached the origin server directly instead of going through Cloudflare.
- Issuer is a national or corporate CA you have never heard of — the root is simply not in your browser’s store.
Then check the same site from another network or device. If the error follows the site everywhere, the site owner has to fix it. If it disappears on mobile data or on another computer, the problem is your device or network.
What causes ERR_CERT_AUTHORITY_INVALID
Self-signed certificate
The certificate is signed with the server’s own key rather than by a certificate authority. Self-signed certificates are perfectly normal for local development and internal appliances (routers, NAS boxes, dev stands), but no public browser trusts them by definition: the issuer exists in no root store. A fresh nginx or Apache install that still serves its default “snakeoil” certificate falls into this bucket too. We cover where self-signed certificates are appropriate and what to replace them with in our self-signed certificate guide.
Incomplete chain: the intermediate certificate is missing
The most common cause on production sites. The server sends only the leaf certificate without the intermediate, so the browser cannot build a path to a trusted root. The trap: desktop Chrome often downloads the missing intermediate itself (AIA fetching), so the owner sees a working site — while Firefox, some mobile browsers and API clients like curl fail. See our deep dive on incomplete certificate chains, and why TLS works in the browser but fails in a client for the API side of the same problem.
Unknown or untrusted certificate authority
The certificate was issued by a CA whose root is not in the browser’s store. This covers internal corporate CAs, authorities removed from root programs after trust incidents, and national CAs that were never accepted by browser vendors. On old devices the reverse happens: the CA is fine, but the device’s root store is frozen and never received the newer root. Android versions before 7.1.1, for example, do not carry ISRG Root X1 and fail on Let’s Encrypt sites since the old cross-signed chain expired in September 2024.
Antivirus with HTTPS inspection
Kaspersky, ESET, Bitdefender, Avast and similar products can inspect HTTPS traffic: they terminate the TLS connection and re-sign it with their own root certificate. If that root failed to install into the system store (or the browser uses its own store), every site starts throwing trust errors. Diagnostic tell: the certificate chain shows an issuer named after the antivirus product.
Wrong date or time on the device
Chain validation includes checking each certificate’s validity period. If the device clock has drifted by months or years (dead CMOS battery, NTP sync disabled), perfectly valid certificates appear expired or not yet valid, and the browser may show trust errors on virtually every site.
Corporate proxy, firewall or intercepting Wi-Fi
Corporate gateways (Zscaler, Squid with SSL bump, FortiGate with deep inspection) intercept TLS the same way antivirus software does. On a managed work laptop the company root is pre-installed and everything works; on a personal device in the same network every HTTPS site fails with ERR_CERT_AUTHORITY_INVALID. Hotel and airport captive portals can produce the same error on the first HTTPS page you open. That is network policy, not a broken site.
Table: cause → who fixes it → solution
| Cause | Who fixes it | Solution |
|---|---|---|
| Self-signed certificate | Site owner | Issue a certificate from a trusted CA (e.g. Let’s Encrypt) |
| Incomplete chain (missing intermediate) | Site owner | Point the server config at the fullchain file, not the leaf only |
| Unknown CA (private or national CA) | Site owner / user | Reissue from a public CA; visitors need a browser or OS with the right root |
| Cloudflare Origin certificate reached directly | Site owner | Proxy the hostname through Cloudflare or install a publicly trusted certificate on the origin |
| Antivirus HTTPS inspection | User | Disable HTTPS scanning or reinstall the antivirus root certificate |
| Wrong date/time | User | Enable automatic time sync and verify the time zone |
| Corporate proxy / FortiGate | User / IT department | Install the organization’s root certificate or switch networks |
| Outdated device root store | User | Update the OS or use a browser that ships its own current root store |
How to fix the NET::ERR_CERT_AUTHORITY_INVALID error as the site owner
Step 1. Diagnose the chain with openssl
Check what your server actually sends. The -servername flag matters: with SNI-based hosting the server may return a different certificate without it.
openssl s_client -connect example.com:443 -servername example.com -showcertsCount the “-----BEGIN CERTIFICATE-----” blocks: one block means only the leaf is served. Then look at the final Verify return code line. The key values:
- 20 (unable to get local issuer certificate) — the issuer of the last certificate sent is unknown locally: usually a missing intermediate or a private CA;
- 21 (unable to verify the first certificate) — the server does not send the intermediate: fix your fullchain;
- 18 (self signed certificate) — self-signed leaf: you need a certificate from a trusted CA (OpenSSL 3 spells it “self-signed certificate”);
- 19 (self signed certificate in certificate chain) — the chain terminates at an unknown root: an internal or untrusted CA, or the traffic is being intercepted;
- 0 (ok) — the chain is valid; look for the problem on the client side.
A shorter version that prints only the issuer, subject and dates of the served certificate:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -datescurl reports the same failure as curl: (60) SSL certificate problem: unable to get local issuer certificate. To confirm locally that your leaf certificate is really signed by your intermediate:
openssl verify -untrusted intermediate.pem certificate.pemStep 2. Serve the full chain (fullchain)
In nginx the ssl_certificate directive must point to a file containing both the site certificate and the intermediates — for Let’s Encrypt that is fullchain.pem, not cert.pem:
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}If your CA sent the certificate and the bundle as separate files, concatenate them in order — leaf first, then intermediates — and never append the root:
cat example_com.crt intermediate_bundle.crt > fullchain.pemIn Apache 2.4.8+ the intermediates go into the same file referenced by SSLCertificateFile (the separate SSLCertificateChainFile directive is deprecated). Reload the web server and re-run the openssl check — the Verify return code should now be 0.
NET::ERR_CERT_AUTHORITY_INVALID after installing a GoDaddy certificate
GoDaddy’s download contains two files: your certificate (a file with a random hexadecimal name) and a bundle file whose name starts with gd_bundle. Installing only the first one is the classic cause of this error on GoDaddy certificates. Build a fullchain from both files as shown above for nginx, or place both in the SSLCertificateFile for Apache. On IIS, import the bundle into the Intermediate Certification Authorities store of the local computer before binding the certificate. The same logic applies to any commercial CA that ships a “CA bundle” or “ca-bundle.crt” next to the certificate.
Behind Cloudflare
A Cloudflare Origin CA certificate is trusted by Cloudflare’s edge, not by browsers. If the DNS record is switched to “DNS only” (grey cloud), or someone opens the origin by its IP or a non-proxied subdomain, the visitor receives that origin certificate directly and sees ERR_CERT_AUTHORITY_INVALID. Either keep the hostname proxied (orange cloud) or install a publicly trusted certificate on the origin. With the “Full (strict)” SSL mode, Cloudflare itself also validates the origin certificate, so a self-signed one fails there as well.
Step 3. Reissue from a trusted CA
If the certificate is self-signed or issued by a CA absent from browser root stores, the only reliable fix is a certificate from a public authority. The free option is Let’s Encrypt: certbot assembles the fullchain and configures auto-renewal for you. See the official Let’s Encrypt documentation for details.
sudo certbot --nginx -d example.com -d www.example.comSelf-signed certificate on localhost
For local development you do not need a public certificate, but you do need a local CA that your machine trusts. The simplest tool is mkcert: it creates a development root, installs it into the system and browser stores, and issues certificates signed by it.
mkcert -install
mkcert localhost 127.0.0.1 ::1Point your dev server at the generated .pem and -key.pem files and restart the browser. Never share the mkcert root key or install it on other people’s machines: anyone holding it can issue certificates your computer will trust.
How to fix it as a user
If the error appears on someone else’s site — and especially on many sites at once — the problem is almost certainly on your side. Work through this list in order:
- Check the date and time. Enable automatic time synchronization and verify the time zone — this is the single most common fix for mass certificate errors.
- Check your antivirus. Temporarily disable encrypted-connection scanning (HTTPS inspection). If the error disappears, reinstall the antivirus root certificate or leave inspection off.
- Switch networks. Error only on office or public Wi-Fi? A proxy is intercepting traffic — contact IT or use another network.
- Try another browser or an incognito window to rule out extensions.
- Update the operating system and browser. Old systems miss newer roots.
What not to do: do not click “Proceed anyway (unsafe)” and do not add permanent exceptions for sites where you enter passwords or payment details. A trust error is exactly the signal that distinguishes the real site from one substituted by an attacker.
Why do I get ERR_CERT_AUTHORITY_INVALID on every website?
When the error hits Google, your bank and every other site at once, no website is at fault — something between your browser and the internet is replacing certificates, or your device cannot validate any of them. Check in this order:
- Clock: on Windows run
w32tm /resyncin an administrator prompt; on macOSsudo sntp -sS time.apple.com; on Linuxtimedatectl set-ntp true. - Issuer on a big site: open the certificate of google.com. If it is issued by anything other than Google Trust Services, something is intercepting your traffic and its name is in that field.
- Security software: antivirus web shields, parental-control apps and ad blockers that work as a local proxy.
- Proxy settings: in Windows, Settings → Network & internet → Proxy; on macOS, System Settings → Network → Details → Proxies. An unexpected proxy there is worth investigating.
- Network: if everything works on mobile data, the Wi-Fi network (router, office gateway, captive portal) is the interceptor.
Chrome and Edge on Windows
Chrome and Edge validate against the Chrome Root Store but still honor roots that you or your administrator installed into the Windows certificate store. Open certmgr.msc (current user) or certlm.msc (local computer) → Trusted Root Certification Authorities to see what is installed. A root named after your antivirus or company explains intercepted connections; a missing corporate root explains why a work site fails on a personal PC. If a site previously used HSTS and now serves a bad certificate, Chrome shows no “Proceed” link at all; the site owner must fix the certificate.
What does NET::ERR_CERT_AUTHORITY_INVALID mean on a Mac?
Exactly the same thing: the certificate does not chain to a root trusted by the browser. On macOS, Chrome and Edge consult the Chrome Root Store plus roots that are trusted in the Keychain, and Safari relies on the Keychain alone. Open Keychain Access → System and check for an unfamiliar root marked “always trust”, and look in System Settings → Privacy & Security → Profiles for a configuration profile you did not install. Also confirm “Set time and date automatically” is on under System Settings → General → Date & Time.
NET::ERR_CERT_AUTHORITY_INVALID on Android
On Android the usual suspects are an outdated system (versions before 7.1.1 lack the ISRG Root X1 root used by Let’s Encrypt), a wrong date after a battery drain, or public Wi-Fi with a login portal. Update Chrome from Google Play and the system if an update is available, set date and time to automatic, and retry on mobile data. For app developers: since Android 7.0, apps do not trust user-installed CA certificates by default unless their network security configuration opts in, which is why a certificate you installed yourself may be accepted in the browser but rejected by an app.
Behind a FortiGate or other corporate firewall
With SSL/SSH deep inspection enabled, FortiGate re-signs HTTPS traffic with its own CA certificate (by default Fortinet_CA_SSL). Devices that do not have that certificate in their trusted root store show ERR_CERT_AUTHORITY_INVALID on every site. Administrators either deploy the inspection CA to managed devices (for example via Group Policy) or switch the profile to certificate inspection, which checks the SNI without decrypting content. Users on unmanaged devices should ask IT rather than install unknown roots themselves.
How can I bypass NET::ERR_CERT_AUTHORITY_INVALID in Chrome?
For a site you do not control, the honest answer is: do not. The warning is the only thing standing between you and a possible man-in-the-middle. For your own router, NAS or test server, Chrome offers “Advanced” → “Proceed to example.com (unsafe)”; Chrome remembers that exception only temporarily. It is not available when the site is on HSTS. The better solution for anything you visit regularly is to make the certificate trusted: import the appliance’s own CA certificate into the system store, use mkcert for development, or issue a public certificate. Clearing HSTS data for a domain is possible under chrome://net-internals/#hsts, but it only removes the block after the certificate problem is fixed. More on HSTS behavior is in our HSTS guide.
Russian certificates: Sberbank, government sites and Russian Trusted CA
Since 2022 a number of Russian banks and government resources use certificates from the national CA operated by the Russian Ministry of Digital Development (Russian Trusted Root CA and Russian Trusted Sub CA). Its root is not included in the Chrome, Firefox or Safari root stores, so those browsers show ERR_CERT_AUTHORITY_INVALID on such sites — expected behavior, not a compromise. We explain the background and which sites are affected in our article on Russian certificate authorities.
Visitors have two options: use a browser that ships the Russian root (Yandex Browser or Atom), or install the ministry’s root certificate manually, downloading it only from the official Gosuslugi page (gosuslugi.ru). Never install root certificates from messengers, emails or third-party sites: whoever controls an installed root can mint certificates for any domain, so a fake root means full interception of your HTTPS traffic.
How to check a certificate and its chain online
Instead of assembling the diagnosis piece by piece, run our free SSL certificate and chain checker: it shows the issuer, validity dates, the full chain up to the root, the intermediates your server actually sends, and warns when the fullchain is misconfigured. Because the check runs from an external server — not from your browser with its cache and antivirus — it tells you what your visitors will really see. If the external check is clean but your browser still complains, the interception is local.
To make sure the fix stays fixed, add the site to uptime and SSL monitoring: a renewal that drops the intermediate, or an origin server that suddenly serves a default certificate, will trigger an alert before visitors report it.
FAQ
How do I fix the NET::ERR_CERT_AUTHORITY_INVALID error?
Read the certificate’s issuer first. A self-signed or private-CA issuer needs a publicly trusted certificate; a public CA with a broken path needs the fullchain on the server; an antivirus, firewall or company issuer means local interception, fixed by the clock, security software or network settings on your side.
Is it safe to click “Proceed anyway”?
Not on sites you do not control: a trust error is indistinguishable from an active man-in-the-middle attack, and anything you type may be readable by the interceptor. The exception is your own equipment — a router or dev stand with a self-signed certificate — when you know exactly what the host is and why its certificate looks that way.
Why does Firefox show the error while Chrome does not?
The classic symptom of an incomplete chain. Desktop Chrome can fetch a missing intermediate via the AIA URL embedded in the certificate; Firefox does not do that on its own. The site “works in the owner’s Chrome” and fails for a share of visitors. The only real fix is serving the fullchain on the server.
How is ERR_CERT_AUTHORITY_INVALID different from ERR_CERT_DATE_INVALID?
ERR_CERT_AUTHORITY_INVALID means the browser distrusts the certificate’s issuer — the chain does not reach a trusted root. ERR_CERT_DATE_INVALID means the certificate is expired or not yet valid. And ERR_SSL_VERSION_OR_CIPHER_MISMATCH is not about trust at all — it signals a TLS protocol version or cipher suite incompatibility between client and server.
Will clearing the browser cache help?
Almost never: certificate validation happens on every TLS handshake and is not served from the page cache. Check the clock, the antivirus and the actual chain via openssl or an online checker first — that removes the cause rather than the symptom.
Will a Let’s Encrypt certificate definitely remove the error?
Yes, when installed correctly, for every modern browser: ISRG Root X1, the root Let’s Encrypt chains terminate at, is present in current root stores. Serve fullchain.pem and configure auto-renewal: Let’s Encrypt certificates live 90 days, and an expired one produces a different error — ERR_CERT_DATE_INVALID.
