How to Fix ERR_CERT_AUTHORITY_INVALID: Complete Guide
ERR_CERT_AUTHORITY_INVALID is one of Chrome's most common SSL warnings. It appears when the browser cannot trace the website's SSL certificate back to a trusted root certificate authority (CA) that ships with your operating system or browser. Instead of loading the page, Chrome displays "Your connection is not private" and names NET::ERR_CERT_AUTHORITY_INVALID as the underlying reason.
The error is not a verdict that the site is malicious — it simply means Chrome cannot verify who signed the certificate. This happens for several legitimate reasons: the server presents a self-signed certificate, the intermediate certificate that links the leaf to a trusted root is missing, the root CA has expired or was distrusted, a corporate firewall is intercepting traffic with its own CA, your operating system's CA bundle is outdated, or the certificate is pinned to an authority Chrome no longer trusts. This guide explains each cause and walks through a complete six-step fix process.
What is ERR_CERT_AUTHORITY_INVALID?
When your browser connects to an HTTPS site, the server sends its SSL/TLS certificate during the TLS handshake. Chrome then tries to build a chain of trust from that leaf certificate up through one or more intermediate CAs to a root CA that is pre-installed in its trust store. If that chain cannot be completed — because an intermediate is missing, the root is not recognized, or the signer is entirely unknown — Chrome aborts the handshake and raises ERR_CERT_AUTHORITY_INVALID.
The distinction from related errors matters. ERR_CERT_DATE_INVALID points at an expiry problem, while ERR_CERT_COMMON_NAME_INVALID points at a hostname mismatch. ERR_CERT_AUTHORITY_INVALID is specifically about the identity and trustworthiness of the issuer, not the dates or the name on the certificate. That is why a certificate can be perfectly valid, unexpired, and issued for the correct domain, yet still trigger this error when the chain to a trusted root is broken.
Common Causes
Six root causes account for almost every occurrence of ERR_CERT_AUTHORITY_INVALID. Identifying which one applies is the fastest route to a fix.
- Self-signed certificate: The server uses a certificate it generated itself, which no public root has signed. Common on internal tools and dev environments.
- Missing intermediate certificate: The leaf certificate is valid, but the server does not send the intermediate needed to bridge it to a trusted root, so the chain cannot be built.
- Expired or distrusted root CA: The root that originally signed the chain has expired or was removed from Chrome's trust store — for example, the older Symantec roots that were distrusted in 2018.
- Corporate MITM proxy: A firewall or security appliance re-signs traffic with its own CA, which is not installed on your machine, so Chrome sees an unfamiliar issuer.
- Outdated OS CA bundle: An older operating system lacks the roots needed to validate newer certificates, such as Let's Encrypt's ISRG Root X1.
- Certificate pinned to the wrong CA: Application-level pinning expects a specific CA, but the certificate was reissued by a different authority, so the pin no longer matches.
Step-by-Step Fix Guide
Work through these six steps in order. The first three address the most common server-side causes; the last three cover client-side and application-level issues.
1. Inspect the Certificate Chain with OpenSSL
Start by seeing exactly what your server sends. Connect with openssl s_client and inspect every certificate in the chain:
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/nullLook at the Verify return code line at the bottom. A value of 0 (ok) means the chain is trusted; anything else, such as unable to get local issuer certificate, confirms a trust gap. Count the certificate blocks — a healthy chain sends at least the leaf plus one intermediate.
2. Identify Self-Signed or Untrusted Issuers
Inspect the issuer of the leaf certificate to learn who signed it:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -issuer -subjectIf the issuer and subject are identical, the certificate is self-signed and no browser will trust it by default. If the issuer names a real CA but verification still fails, the problem is a missing intermediate or an outdated root store — continue to the next steps.
3. Install the Missing Intermediate Certificate
The most frequent server-side fix is to serve the full chain. Download the intermediate from your CA, concatenate the leaf and intermediate into a single fullchain.pem, and point your web server at it:
cat example.com.crt intermediate.crt > fullchain.pem
# Reload the server
sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2In Nginx, set ssl_certificate to fullchain.pem. In Apache, set SSLCertificateFile to fullchain.pem. Reload and re-test with openssl s_client until the verify code reads 0 (ok).
4. Update the OS and Browser CA Bundle
If the certificate is valid and the chain is complete but the error persists on one machine, the local trust store is likely outdated. Update the CA package and the browser:
# Debian / Ubuntu
sudo apt-get update && sudo apt-get install --only-upgrade ca-certificates
# RHEL / CentOS / Fedora
sudo dnf upgrade ca-certificates
# Update Chrome, then check its version
chrome://settings/helpRestart the machine after updating so the new root store loads. This resolves errors caused by recently added roots such as ISRG Root X1, or by the removal of legacy roots.
5. Trust or Bypass a Corporate MITM Proxy
If the error appears only on a company network, a security appliance is likely intercepting HTTPS with its own CA. Confirm by inspecting the issuer — if it names your employer or a vendor like Zscaler, Netskope, or Fortinet, a MITM proxy is in play. Install the proxy's root certificate into your system trust store so Chrome can validate the re-signed certificates:
# Linux: copy the proxy CA into the trust store
sudo cp corporate-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates
# Windows: add to the Trusted Root Certification Authorities store
certutil -addstore -f "Root" corporate-ca.crtIf you cannot install the CA, the only safe options are to use a different network or to ask IT to publish the certificate. Never disable certificate validation globally to bypass the warning.
6. Fix Certificate Pinning to the Wrong CA
When the error appears in a single mobile or desktop app but not in Chrome, the app likely uses certificate pinning. After a certificate is reissued by a different CA, the stored pin no longer matches and the app rejects the connection. Update the pin to the new CA's public key, or better, pin to the leaf's SPKI and rotate pins during transitions:
# Extract the SPKI hash for the new certificate
openssl x509 -in example.com.crt -pubkey -noout \
| openssl pkey -pubin -outform der \
| openssl dgst -sha256 -binary \
| openssl base64Ship the new pin in an app update and keep the old pin valid during the overlap window so existing installs keep working until users upgrade.
SSL Diagnostic Commands
The commands below give you a complete picture of the certificate, its chain, and the local trust store. Run them from a terminal on the machine that sees the error.
# 1. Print the full chain the server presents
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
# 2. Show validity dates, issuer, subject, and SANs
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -dates -issuer -subject -ext subjectAltName
# 3. Verify the chain against the system trust store
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt example.com.crt
# 4. Windows: list trusted root CAs
certutil -store Root | findstr /C:"Cert:"
# 5. Java: list CAs trusted by the JDK
keytool -list -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit
# 6. Check whether a specific root is present
trust anchor --list | grep -i "ISRG Root X1"Quick Reference Table
Use this table to match a symptom to its root cause and the corresponding fix.
| Symptom | Cause | Fix |
|---|---|---|
| Only your machine sees the error | Corporate MITM proxy or outdated CA bundle | Install the proxy CA (Step 5) or update the OS (Step 4) |
| Everyone sees the error; cert is from a real CA | Missing intermediate certificate | Serve fullchain.pem (Step 3) |
| Error on internal or dev site only | Self-signed certificate | Use a real CA or install the cert locally |
| Started right after a certificate renewal | New CA not yet trusted or pinning mismatch | Update the pin (Step 6) or wait for CA propagation |
| Works on a new OS, fails on an old OS | Outdated CA bundle missing a newer root | Update the OS CA bundle (Step 4) |
| Error appears in one app, not in Chrome | Certificate pinned to the wrong CA | Update the pin to the new CA's SPKI (Step 6) |
FAQ
Is it safe to click "Proceed to site" when I see ERR_CERT_AUTHORITY_INVALID?
Generally no. Clicking through disables Chrome's protection and exposes you to potential man-in-the-middle attacks. Only bypass the warning on a trusted internal network where you control the certificate, such as a development server, and never on public sites or when entering credentials. Investigate the cause with the steps above first.
Why does the error appear on my company network but not at home?
Your company likely runs an HTTPS inspection proxy that re-signs traffic with its own certificate authority. At home there is no interception, so Chrome trusts the site's original certificate. The fix is to install the company's root CA into your trust store (Step 5), which IT should provide.
How do I fix the error for a self-signed certificate on localhost?
Use mkcert to generate a locally trusted certificate instead of a raw self-signed one. mkcert installs a local root CA into your system trust store, so Chrome accepts certificates it issues for localhost and any dev domain. Alternatively, expose the dev server through a tunnel such as ngrok to get a CA-backed certificate automatically.
Can an expired root certificate cause ERR_CERT_AUTHORITY_INVALID even if my site certificate is valid?
Yes. If the root CA that ultimately signed your chain has expired or was distrusted, Chrome can no longer build a trusted path even though your leaf certificate is valid and unexpired. The classic example is the 2018 distrust of older Symantec roots. The fix is to reissue the certificate through a currently trusted CA and serve the new chain.
Conclusion
ERR_CERT_AUTHORITY_INVALID always means the same thing: Chrome cannot build a chain of trust from the server's certificate to a root it recognizes. The cause is almost always one of six — a self-signed certificate, a missing intermediate, an expired or distrusted root, a corporate MITM proxy, an outdated CA bundle, or a stale certificate pin. Work through the six steps in order: inspect the chain, identify the issuer, install the intermediate, update the trust store, handle any proxy, and fix pinning.
Once the error clears, keep certificates renewed automatically, always serve the full chain, and update your operating system regularly so the root store stays current. A little proactive maintenance prevents this warning from disrupting your users.