ERR_CERT_AUTHORITY_INVALID

ERR_CERT_AUTHORITY_INVALID means one thing: the browser doesn't trust whoever signed your certificate.

This isn't a technicality. It's the browser asking a fundamental question about identity: "Who vouches for this website?" If the answer isn't someone the browser already trusts, the connection stops.

Why Trust Matters

Anyone can create a certificate claiming to be bank.com. The cryptography works the same whether you're the real bank or an attacker on a coffee shop WiFi network. The certificate itself proves nothing about identity.

This is the problem Certificate Authorities solve. A CA verifies that you control a domain before signing your certificate. When the browser sees that signature, it knows a trusted third party checked. The signature from a trusted CA is the only thing that makes your certificate different from an attacker's.

Browsers ship with a built-in list of trusted CAs—organizations that have been audited and agreed to strict issuance practices. If your certificate wasn't signed by one of these CAs (or by an intermediate that chains to one), the browser rejects it.

The Most Common Cause: Self-Signed Certificates

Self-signed certificates trigger this error more than anything else.

A self-signed certificate is one you create yourself, signed with your own key rather than a CA's. The browser isn't being paranoid when it rejects these—it's asking a reasonable question: "Who vouches for you?" Self-signed certificates answer: "I vouch for myself."

That's not verification. That's just assertion.

Self-signed certificates are fine for local development or internal tools where you can manually verify what you're connecting to. They have no place on public websites. Let's Encrypt provides free, automated, browser-trusted certificates. There's no legitimate reason to use self-signed certificates in production.

Private Certificate Authorities

Organizations sometimes run their own internal CAs for corporate websites. These certificates work fine—until someone outside your network tries to connect.

The fix is distributing your internal CA's root certificate to all machines that need to trust it:

• Windows: Group Policy deployment to the trusted root store
• macOS: MDM or Configuration Profiles
• Linux: Add to /etc/ssl/certs or equivalent

For external users, internal CAs don't work. Use publicly-trusted certificates instead.

Incomplete Certificate Chains

Your certificate might be from a trusted CA, but the browser still shows this error. The usual culprit: incomplete certificate chains.

Here's how certificate chains work: Your certificate is signed by an intermediate CA. That intermediate is signed by a root CA. Browsers only store root CAs. If your server doesn't send the intermediate certificate, the browser can't verify the path from your certificate to a trusted root.

The fix: Configure your server to send the complete chain. Most CAs provide a "bundle" or "chain" file containing intermediates. Combine your certificate with this file (your certificate first, then intermediates).

Test with SSL Labs—it shows exactly which intermediates are missing.

Distrusted Certificate Authorities

CAs can lose browser trust. In 2018, Google distrusted all Symantec-issued certificates after discovering improper issuance practices. Websites using those certificates suddenly showed errors.

If your CA has been distrusted, the only fix is replacing your certificate with one from a currently-trusted CA. Monitor browser vendor announcements about CA trust changes.

Antivirus and Corporate Proxies

Sometimes the error indicates interception, not a problem with your website.

Some antivirus software and corporate proxies intercept HTTPS connections, replacing certificates with their own. If the replacement certificate isn't properly trusted on the user's machine, they see ERR_CERT_AUTHORITY_INVALID.

This is a client-side issue. Website operators can't fix it. Users should check with their IT department or verify their security software's certificate is properly installed.

Fixing the Error

If you operate the website:

1. View the certificate in your browser to identify the issuer
2. If self-signed: Get a certificate from Let's Encrypt or a commercial CA
3. If from a trusted CA: Test with SSL Labs to verify your chain is complete
4. If from a distrusted CA: Replace with a certificate from a currently-trusted CA

If you're visiting a website:

1. Verify the URL is correct—typos can lead to malicious sites
2. Test on another device or network
3. If the site normally works, try again later
4. Don't bypass the warning unless you absolutely understand the risk

Testing After Fixes

Run your domain through SSL Labs. It should show a complete, trusted certificate chain with no warnings.

Test in multiple browsers—Firefox maintains its own trust store separate from Chrome and Safari. Test on mobile devices too; their trust stores occasionally differ from desktop.

Prevention

• Use Let's Encrypt or well-known commercial CAs for public sites
• Automate certificate management with ACME clients like Certbot
• Always configure servers to send complete certificate chains
• Monitor for certificate expiration and CA trust changes
• Follow browser vendor announcements about CA policy updates