Fix ERR_CERT_AUTHORITY_INVALID: Causes and Solutions

ERR_CERT_AUTHORITY_INVALID is a Chrome error meaning the browser does not trust the certificate authority (CA) that issued the site’s SSL certificate. Common causes: a self-signed certificate, an incomplete chain missing the intermediate certificate, an unknown CA, antivirus SSL/TLS проверку inspection, or a wrong system clock. Site owners fix it by serving the fullchain and using a trusted CA; visitors fix it by checking their clock and antivirus.

This guide explains how browsers build the chain of trust, walks through all six typical causes of NET::ERR_CERT_AUTHORITY_INVALID, and gives separate step-by-step fixes for site owners (openssl diagnostics, fullchain, reissuing) and for regular users. There is also a dedicated section on Russian Trusted CA certificates used by Sberbank and Russian government sites.

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. Since 2022 Chrome ships its own store governed by the Chrome Root Program: if the chain does not terminate at a root on that list, 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.

Other browsers surface the same failure differently: Firefox shows SEC_ERROR_UNKNOWN_ISSUER or MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, Safari says “This Connection Is Not Private”. Note the distinction: this error is about distrust of the certificate’s issuer — not an expired certificate (that is ERR_CERT_DATE_INVALID) and not a hostname mismatch (ERR_CERT_COMMON_NAME_INVALID). A short reference entry lives in our glossary: ERR_CERT_AUTHORITY_INVALID.

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. 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, mobile browsers and API документацию clients like curl fail. See our deep dive on incomplete certificate chains.

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, and Russian CAs: the Russian Trusted Root CA operated by the Ministry of Digital Development is not included in the Chrome, Firefox or Safari root stores, so sites using those certificates trigger ERR_CERT_AUTHORITY_INVALID for most of the world’s browsers.

Antivirus with HTTPS inspection

Kaspersky, ESET, Bitdefender 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 or intercepting Wi-Fi

Corporate gateways (Zscaler, Squid with SSL bump, FortiGate) 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. That is network policy, not a broken site.

Table: cause → who fixes it → solution

How to fix it 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 -showcerts

Look at the final Verify return code line. The key values:

• 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;
• 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.

To confirm locally that your leaf certificate is really signed by your intermediate:

openssl verify -untrusted intermediate.pem certificate.pem

Step 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;
}

In 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.

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.com

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:

1. Check the date and time. Enable automatic time synchronisation and verify the time zone — this is the single most common fix for mass certificate errors.
2. Check your antivirus. Temporarily disable encrypted-connection scanning (HTTPS inspection). If the error disappears, reinstall the antivirus root certificate or leave inspection off.
3. Switch networks. Error only on office or public Wi-Fi? A proxy is intercepting traffic — contact IT or use another network.
4. Try another browser or incognito mode to rule out extensions.

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.

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 Ministry of Digital Development (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 behaviour, 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) — the safest path; 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.

Frequently Asked Questions

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 and most mobile browsers do not. 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. Clearing data helps only in the rare case of a cached HSTS state for the domain. 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. ISRG Root X1, the root Let’s Encrypt chains terminate at, is present in every modern browser’s root store. Just remember to 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.