ERR_CERT_AUTHORITY_INVALID: Fix in Chrome, Edge & Android

What Is NET::ERR_CERT_AUTHORITY_INVALID?

NET::ERR_CERT_AUTHORITY_INVALID means your browser doesn't trust whoever issued the website's certificate. Chrome shows "Your connection is not private", and under Advanced it says the server "could not prove that it is example.com" because its security certificate isn't trusted, which "may be caused by a misconfiguration or an attacker intercepting your connection." Chromium lists it as error -202 (net_error_list.h).

The connection was set up, the server sent its certificate, and the browser couldn't link it to a certificate authority (CA) it trusts. Chromium's own notes give three reasons: an attacker substituted the certificate, the site uses a CA the browser doesn't know, or the certificate is self-signed.

If a certificate has several problems, Chrome shows only the most serious one, and an untrusted issuer outranks a wrong name or an expired date. So a self-signed certificate that is also expired shows this code, not ERR_CERT_DATE_INVALID.

What ERR_CERT_AUTHORITY_INVALID Looks Like in Each Browser

Each browser words it differently. Look for these:

How SSL Certificate Trust Works (Chain of Trust)

Every certificate hangs off a chain of trust that ends at a root certificate authority the browser already trusts.

When you connect, the server sends its own certificate plus one or more intermediates. The browser checks that the site's certificate was signed by the intermediate, and the intermediate by a root on its list. Chrome no longer uses your operating system's list for this: it has carried its own, the Chrome Root Store, on Windows and macOS since Chrome 108 and on Android since Chrome 115 (not on iPhone and iPad, where Apple's list is required). That list has about 100 roots and updates in the background (Chrome Root Store). On Windows and macOS, Edge ships Microsoft's list; Firefox ships Mozilla's; and all of them also trust roots you or your company add to the computer.

If any link is missing or unknown, you get this error (more in what an SSL certificate chain is). The chain has four parts:

• Root CA — self-signed and built into the browser's root list
• Intermediate CA — signed by the root; the server must send it. Chrome downloads a missing one from the address in the certificate, but curl, apps and many other clients can't
• Site certificate — signed by the intermediate, for the names in its Subject Alternative Name list
• Validation — the browser walks from the site certificate up to a trusted root; every signature must check out

What Causes NET::ERR_CERT_AUTHORITY_INVALID?

Where you see it narrows the cause: one website means the problem is almost always that site's certificate. Every HTTPS site means it's your device or network.

Fixes for Website Visitors (Client-Side)

If you're seeing the error on a site you don't run, try these in order. Never type a password or card number on a page showing this warning.

Fix 1: Sign In to the Wi-Fi or Try Another Network

Hotel, airport and café Wi-Fi often hijack your first connections to show a sign-in page, and an HTTPS site then gets the network's certificate instead of its own. Chrome's help says these networks need you to sign in, and that visiting a page that uses http:// brings up the sign-in page; Chrome may also show a "Connect to Wi-Fi" page instead of this error. Accept the sign-in, then reload.

Company and school networks may also inspect HTTPS with their own certificate. If the error disappears on mobile data, ask the network's IT team: devices they manage normally have their root installed, and yours may not.

Fix 2: Check Antivirus HTTPS Scanning

Antivirus suites such as Kaspersky, Avast, ESET and Bitdefender can scan HTTPS by decrypting it with their own certificate and re-encrypting it. If their root certificate isn't trusted by your browser, or the feature breaks after an update, every HTTPS site shows this error at once.

To test, pause only the HTTPS or web scanning feature and reload. If the error goes away, repair or update the antivirus so it reinstalls its certificate, or leave HTTPS scanning off.

Fix 3: Update Your Browser and Operating System

Browsers and operating systems update their root lists regularly (Chrome through background component updates), and old systems miss newer roots. Android versions older than 7.1.1, for example, don't trust ISRG Root X1, so Let's Encrypt sites fail there in browsers and apps that rely on the system's list.

Update the browser first: Chrome and Edge carry their own root lists on Windows and macOS, and Chrome does on Android from version 115. Then update the operating system.

Fix 4: Check Your Date and Time

A clock that's months or years off makes certificates look not yet valid or expired. Chrome usually shows a separate warning for that ("Your clock is behind" or ERR_CERT_DATE_INVALID), but a wildly wrong clock after a dead CMOS battery or a restored virtual machine can break trust checks too. It takes ten seconds to rule out.

Windows: Settings → Time & language → Date & time → turn on Set time automatically. macOS: System Settings → General → Date & Time → Set time and date automatically. Android: Settings → System → Date & time → Set time automatically (Automatic date and time on Android 16).

Fix 5: Try Incognito, Then Restart the Browser

An Incognito window (Ctrl+Shift+N in Chrome and Edge, Ctrl+Shift+P for a private window in Firefox) runs without your extensions unless you allowed them. VPN and proxy extensions can route your traffic through a server that presents its own certificate; if the site works in Incognito, turn extensions off at chrome://extensions and back on one at a time.

If the site just fixed its certificate, close every browser window and reopen it, so the browser checks the new one from scratch.

Fix 6: On Android

Android adds a few checks of its own:

• Set the date and time automatically: Settings → System → Date & time.
• Update Chrome and Android System WebView from the Play Store. Apps that show web pages through WebView check certificates against Android's own root list, so an old Android version can still fail there.
• Turn off VPN, ad-blocking or "safe browsing" apps that filter HTTPS; they show a key or VPN icon in the status bar.
• Sign in to the Wi-Fi: public networks show the error until you accept their sign-in page.
• On Android older than 7.1.1, Let's Encrypt's root isn't in the system's list, so apps and browsers that rely on it can't verify those sites. A browser that carries its own root list is the only workaround.

Fixes for Website Owners (Server-Side)

If visitors report NET::ERR_CERT_AUTHORITY_INVALID on your site, the certificate you serve usually doesn't chain to a public root. Check it first with the SSL Checker, then fix what it finds. If it shows a different certificate from the one you installed, confirm with DNS Lookup that the domain points at the server you think, and with the HTTP Header Checker which server answers.

Fix 1: Install a Certificate from a Trusted CA

A self-signed certificate, or one from your own CA, will never be trusted by visitors' browsers: the signer isn't on any public root list.

Install a certificate from a publicly trusted CA instead. Let's Encrypt issues free, automated certificates trusted by every major browser; DigiCert, Sectigo and GlobalSign sell certificates with organization validation and support.

# Install Let's Encrypt certificate with Certbot (Nginx)
sudo certbot --nginx -d example.com -d www.example.com

# Install Let's Encrypt certificate with Certbot (Apache)
sudo certbot --apache -d example.com -d www.example.com

# Verify the installed certificate
sudo certbot certificates

Fix 2: Send the Complete Certificate Chain

Your certificate can be perfectly valid while the server forgets to send the intermediate. Chrome often papers over this by downloading the missing intermediate itself, so the site works in Chrome and fails in curl, apps, payment callbacks and some phones.

Run the site through DNS Robot's SSL Checker: it shows the chain your server sends and whether Mozilla, Chrome, Apple and Microsoft each trust it. Or check from a terminal:

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# letsencrypt.org on 26 Oct 2026, a complete chain:
#  0 s:CN=letsencrypt.org
#    i:C=US, O=Let's Encrypt, CN=YE2
#  1 s:C=US, O=Let's Encrypt, CN=YE2
#    i:C=US, O=ISRG, CN=Root YE
#  2 s:C=US, O=ISRG, CN=Root YE
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X2
#  3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2
#    i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
# Only certificate 0 listed = the intermediate is missing.

# nginx: point ssl_certificate at the full chain, not the leaf alone
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# Apache 2.4.8+
SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

Fix 3: Renew an Expired Certificate

An expired certificate from a trusted CA shows ERR_CERT_DATE_INVALID, not this error. You'll see ERR_CERT_AUTHORITY_INVALID only if the chain is also untrusted, because Chrome reports the more serious problem. Either way, check the dates and renew:

# Check the certificate's dates
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates
# notBefore=Sep 30 12:00:00 2026 GMT
# notAfter=Dec 29 11:59:59 2026 GMT

# Renew now with Certbot, then reload the web server
sudo certbot renew --force-renewal
sudo systemctl reload nginx    # or apache2

Fix 4: Cover Every Name Visitors Use

A trusted certificate that doesn't list the name in the address bar shows ERR_CERT_COMMON_NAME_INVALID instead. It only turns into this error when the certificate is untrusted as well, so fix the trust first, then the names.

Browsers check only the Subject Alternative Name list, not the old Common Name. A wildcard (*.example.com) covers one level of subdomains but not example.com itself, so list both when you request it. The SSL Checker shows a certificate's full name list.

Fix 5: Using a Private or Company CA

Internal sites often use a company CA on purpose. That works only on devices where the company's root certificate is installed, and Chrome and Edge trust a root added to Windows or macOS (Chrome Root Store FAQ). Push it with Group Policy or your device management tool, or add it by hand:

# Windows (Command Prompt as Administrator): trust for all users
certutil -addstore -f Root company-root.crt

# macOS: trust in the System keychain
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain company-root.crt

ERR_CERT_AUTHORITY_INVALID on Localhost (Developers)

A local HTTPS server with a self-signed certificate shows this error by design. Make the certificate trusted on your own machine instead of clicking through:

• mkcert — mkcert -install creates a local CA and adds it to your system's trust store (and Firefox's, once certutil from NSS is installed); then mkcert localhost 127.0.0.1 ::1 makes a certificate Chrome, Edge and Firefox trust
• Next.js — next dev --experimental-https creates a locally trusted certificate with mkcert for you
• Vite — @vitejs/plugin-basic-ssl makes an untrusted certificate, so you'll still see this error; point server.https at mkcert's files instead
• Old tips that no longer work — the chrome://flags/#allow-insecure-localhost switch expired after Chrome 130 and is no longer in chrome://flags

# Install mkcert (macOS)
brew install mkcert
mkcert -install

# Generate localhost certificate
mkcert localhost 127.0.0.1 ::1
# Creates: localhost+2.pem and localhost+2-key.pem

# Use with Node.js
const https = require('https');
const fs = require('fs');
https.createServer({
  cert: fs.readFileSync('localhost+2.pem'),
  key: fs.readFileSync('localhost+2-key.pem')
}, app).listen(3000);

Related SSL Certificate Errors

NET::ERR_CERT_AUTHORITY_INVALID is one of several certificate errors behind Chrome's "Your connection is not private" page. Each code points at a different check: