NET::ERR_CERT_AUTHORITY_INVALID means your browser doesn’t trust the SSL certificate presented by a website—usually because it’s self-signed, expired, or issued by an unknown certificate authority. You can fix it by installing a proper certificate from Let’s Encrypt or a commercial CA, updating your system’s trust store, or temporarily bypassing the warning in local development environments.
Over 95% of web traffic now flows over HTTPS, according to Google’s Transparency Report. When users hit a certificate error, bounce rates spike—most visitors close the tab within three seconds rather than clicking through a security warning. For site owners, that’s lost revenue. For developers, it’s a blocker that stops testing cold.
This error fires when Chrome (or any Chromium-based browser) checks the certificate chain and finds a root CA it doesn’t recognize. Every SSL certificate is signed by a certificate authority. Your operating system and browser ship with a list of trusted root CAs—Sectigo, DigiCert, Let’s Encrypt, and about 150 others.
When the signing CA isn’t in that list, the handshake fails. The browser refuses to encrypt traffic because it can’t verify the server’s identity. You’ll see the same error with different codes in other browsers: Firefox shows SEC_ERROR_UNKNOWN_ISSUER, Safari says “This Connection Is Not Private.”
Common triggers include self-signed certificates on staging servers, misconfigured reverse proxies that strip the intermediate certificate, and corporate middleboxes that intercept TLS without installing their root CA on employee machines.
If you control the server throwing the error, start here. Check your certificate’s issuer and expiration date:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -issuer -datesYou’ll see the issuer DN and the NotBefore/NotAfter timestamps. If the issuer is your own hostname or “self-signed,” that’s the problem. Replace it with a certificate from a recognized CA.
Let’s Encrypt is free and trusted by every major browser. Install Certbot, then run:
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.comFor Apache, swap --nginx for --apache. Certbot handles the ACME challenge, writes the certificate files, and updates your web server config. Renewal happens automatically via a cron job or systemd timer.
If you’re behind a load balancer or CDN, check whether the origin certificate is visible to clients. Cloudflare’s “Full (strict)” mode requires a valid cert on your origin; “Flexible” mode uses Cloudflare’s cert to the browser but HTTP to your server. That’s fine for the browser, but it leaves your origin unencrypted. Pin a Cloudflare Origin CA certificate on your server or use a Let’s Encrypt cert that Cloudflare can verify.
A missing intermediate certificate is the second-most-common cause I’ve debugged. Your server needs to send the full chain: your domain certificate, then every intermediate CA certificate, up to (but not including) the root.
Most CAs provide a “fullchain” bundle. For Let’s Encrypt, Certbot writes fullchain.pem automatically. Point your Nginx config at it:
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;Test the chain with SSL Labs’ server test. It’ll flag a broken chain before your users see the error. If the intermediate is missing, concatenate it manually:
cat yourdomain.crt intermediate.crt > fullchain.crtOrder matters—domain cert first, then intermediates in signing order.
Self-signed certs are fine for local testing, but you have to tell your system to trust them. Generate one with OpenSSL:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes -subj "/CN=localhost"On macOS, double-click cert.pem to open Keychain Access, then mark it “Always Trust” under the certificate’s Trust settings. On Ubuntu or Debian, copy it to /usr/local/share/ca-certificates/ and run sudo update-ca-certificates. Windows users open certmgr.msc, import the cert into “Trusted Root Certification Authorities,” and restart the browser.
For Node.js apps, set NODE_EXTRA_CA_CERTS=/path/to/cert.pem in your environment. Docker containers won’t inherit your host’s trust store—mount /etc/ssl/certs or copy the CA bundle into the image and update ca-certificates inside the container.
Clock skew breaks TLS. If your server’s time is off by more than five minutes, the certificate’s validity window won’t overlap with the client’s current time. Check with timedatectl or date, then sync via NTP:
sudo timedatectl set-ntp trueAnother edge case: SNI mismatch. If your server hosts multiple domains and the client doesn’t send the Server Name Indication extension, the server might return the wrong certificate. Modern browsers always send SNI, but old HTTP clients and some API tools don’t. Check your server’s default vhost or add a catch-all that returns the correct cert.
Antivirus software and corporate proxies sometimes inject their own certificates to scan encrypted traffic. Kaspersky, Avast, and Zscaler all do this. The error appears if the proxy’s root CA isn’t installed on the machine. Users see NET::ERR_CERT_AUTHORITY_INVALID even though the upstream site has a valid certificate. In corporate environments, IT pushes the proxy’s CA via Group Policy or MDM. At home, check your antivirus settings and disable SSL scanning if it’s causing problems.
Chrome and Edge use the operating system’s trust store on Windows and macOS. On Linux, Chromium reads /etc/ssl/certs. Firefox maintains its own store, derived from Mozilla’s CA Certificate Program. Apple’s list is in the Keychain system roots. These lists change—CAs get added when they pass audits, and revoked when they issue fraudulent certificates or fail compliance checks.
In 2022, the CA/Browser Forum tightened DV certificate lifespans to 398 days. Certificates issued for longer periods won’t be trusted even if the CA is recognized. Let’s Encrypt issues 90-day certificates by design, forcing automation and reducing exposure if a key is compromised.
Chrome hides the “Proceed anyway” option for HSTS-enabled sites. For others, you can click “Advanced” and then “Proceed to [site].” Don’t do this on public networks or for sites handling logins or payments—you’re disabling the encryption guarantee that HTTPS provides.
Mobile OS trust stores update less frequently, especially on older Android versions. A newly issued intermediate CA might be recognized by your desktop but not by a phone running Android 9. The fix is to include the full certificate chain on your server so the client can build the trust path.
No. Certificate validation happens during the TLS handshake, before any HTTP requests or caching. Clearing cache won’t help. You need to fix the certificate itself or update the trust store.
Only if the hostname resolves to a public IP during the ACME challenge. For internal-only hosts, use a DNS-01 challenge with a wildcard certificate, or run a private CA like Smallstep and distribute its root to your internal machines.
Click the padlock icon in Chrome’s address bar, then “Connection is secure” → “Certificate is valid.” The Details tab shows the issuer organization. Firefox’s Page Info (Ctrl+I) has a Security tab with the same information. Online tools like SSL Labs and SSL Checker decode the certificate for you if you prefer a web interface.