How to Fix the NET::ERR_CERT_AUTHORITY_INVALID Error

NET::ERR_CERT_AUTHORITY_INVALID is a browser-level TLS handshake failure that occurs when the certificate presented by a web server cannot be traced back to a root Certificate Authority (CA) trusted by the browser's built-in trust store. The browser terminates the connection before any data is exchanged, displaying this error to prevent exposure to man-in-the-middle (MITM) attacks, data interception, or traffic from a spoofed server.

This is not a cosmetic warning. It is a hard cryptographic verification failure. The browser has inspected the certificate chain, attempted to validate each link up to a trusted root, and found the chain broken, absent, or cryptographically invalid. Understanding exactly where that chain breaks is the difference between a five-minute fix and hours of misdiagnosis.

What Actually Triggers This Error

Most documentation lists surface-level causes. The real picture is more nuanced, and each root cause demands a different remediation path.

Self-Signed Certificates

A self-signed certificate is one where the issuer and the subject are identical — the server signed its own certificate rather than having a trusted CA sign it. These are standard in local development environments, internal staging servers, and private infrastructure. No public browser trust store recognizes them, so the chain validation fails immediately.

Critical nuance: Even if you add a self-signed cert to your OS trust store, some browsers (notably Chrome on certain platforms) use their own certificate store and will still reject it unless explicitly configured.

Expired SSL/TLS Certificate

Every certificate carries a `notBefore` and `notAfter` field encoded in its X.509 structure. Once the system clock passes the `notAfter` timestamp, the certificate is cryptographically invalid regardless of how it was issued. Browsers enforce this strictly.

Edge case: If your server's clock drifts significantly forward, a certificate that is technically still valid may appear expired to the server itself during the TLS handshake negotiation, causing this error from the server side rather than the client side.

Incomplete Certificate Chain (Missing Intermediate CA)

This is the most commonly misdiagnosed cause in production environments. A trusted root CA does not directly sign end-entity certificates. It signs intermediate CAs, which then sign your certificate. When you install an SSL certificate on a server, you must install the full chain: your end-entity certificate plus all intermediate certificates concatenated in order.

If the intermediate is missing from the server's TLS response, most browsers cannot complete the chain walk to a trusted root. Firefox is somewhat more forgiving here because it caches intermediates from previous sessions (AIA fetching), but Chrome and Edge will fail hard.

How to verify: Run `openssl s_client -connect yourdomain.com:443 -showcerts` and inspect whether the full chain is returned.

Mismatched Certificate Common Name or SAN

If a certificate was issued for `www.example.com` but the user is accessing `example.com` (or a subdomain not covered by a wildcard), the browser will raise a related but distinct error. However, in some configurations this manifests as an authority invalid error rather than a name mismatch error, particularly with older certificate formats that lack Subject Alternative Names (SANs).

Client-Side Clock Skew

TLS certificates are time-bounded. If the client machine's clock is set to a date before the certificate's `notBefore` field or after its `notAfter` field, the browser will reject it. This is extremely common on virtual machines, freshly provisioned servers, or machines that have been powered off for extended periods without NTP synchronization.

SSL Inspection by Security Software

Corporate firewalls, endpoint security suites, and some antivirus products perform SSL/TLS inspection (also called HTTPS interception). They terminate the TLS connection at the security appliance, inspect the plaintext, then re-encrypt it using a dynamically generated certificate signed by the appliance's own CA. If that appliance CA is not in the browser's trust store, every HTTPS site will trigger this error.

Outdated Root Certificate Store

On older operating systems (Windows 7 without updates, legacy Linux distributions), the system root CA bundle may not include newer root certificates. Let's Encrypt's ISRG Root X1, for example, caused widespread errors on Android 7 and below and on unpatched Windows systems when the DST Root CA X3 cross-signature expired in September 2021.

Root Cause Comparison

Step-by-Step Fixes

Step 1: Synchronize System Date and Time

This is the fastest fix when the error appears suddenly on a machine that was previously working.

Windows:

1. Open Settings > Time & Language > Date & time.
2. Enable Set time automatically and Set time zone automatically.
3. Click Sync now under "Synchronize your clock."
4. If automatic sync fails, open Command Prompt as Administrator and run: `w32tm /resync /force`

macOS:

1. Open System Settings > General > Date & Time.
2. Enable Set time and date automatically and select a nearby NTP server (e.g., `time.apple.com`).
3. If the problem persists, run in Terminal: `sudo sntp -sS time.apple.com`

Linux (server or desktop):

“`bash

sudo timedatectl set-ntp true

sudo systemctl restart systemd-timesyncd

timedatectl status

“`

After synchronizing, restart the browser and retry.

Step 2: Clear Browser Cache, Cookies, and Cached Certificates

Browsers cache HSTS (HTTP Strict Transport Security) policies and certificate data. A stale cache entry can perpetuate an error even after the underlying issue is resolved.

Google Chrome:

1. Navigate to `chrome://settings/clearBrowserData`.
2. Set time range to All time.
3. Check Cookies and other site data and Cached images and files.
4. Click Clear data.

For HSTS-specific cache clearing in Chrome, navigate to `chrome://net-internals/#hsts`, enter the domain under "Delete domain security policies," and click Delete.

Mozilla Firefox:

1. Open Settings > Privacy & Security.
2. Under Cookies and Site Data, click Clear Data.
3. Also clear Cached Web Content.

Microsoft Edge:

1. Navigate to `edge://settings/clearBrowserData`.
2. Select All time and clear cached data and cookies.

Step 3: Identify and Disable SSL Inspection

If you are on a corporate network or using an endpoint security product, SSL inspection is a prime suspect.

1. Click the padlock icon (or warning icon) in the browser address bar.
2. Inspect the certificate details. If the issuer is your antivirus vendor (e.g., "Avast Root," "Kaspersky Anti-Virus," "ESET SSL Filter CA") rather than a public CA like DigiCert, Let's Encrypt, or Sectigo, SSL inspection is active.
3. In your antivirus or firewall settings, locate HTTPS scanning, SSL filtering, or Web Shield and disable it.
4. Alternatively, add the appliance's root CA certificate to your browser's trust store.

Do not permanently disable your security software. Re-enable it after testing, or configure it to exclude specific trusted domains.

Step 4: Verify and Repair the Server-Side Certificate Chain (Server Administrators)

This is the correct fix for production websites where visitors are seeing the error.

Diagnose the chain:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null | openssl x509 -noout -text | grep -E "Issuer:|Subject:"

“`

Or use the full chain inspection:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts

“`

Count the certificates returned. You should see at least two (end-entity + intermediate). If only one appears, the intermediate is missing.

Fix in Apache (`httpd.conf` or virtual host file):

“`apache

SSLCertificateFile /etc/ssl/certs/yourdomain.crt

SSLCertificateKeyFile /etc/ssl/private/yourdomain.key

SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

“`

Fix in Nginx (`nginx.conf` or server block):

Nginx requires the full chain to be concatenated into a single file:

“`bash

cat yourdomain.crt intermediate.crt > fullchain.pem

“`

Then reference it:

“`nginx

ssl_certificate /etc/ssl/certs/fullchain.pem;

ssl_certificate_key /etc/ssl/private/yourdomain.key;

“`

After editing, always test the configuration before restarting:

“`bash

Apache

apachectl configtest

Nginx

nginx -t

“`

Then reload the service:

“`bash

sudo systemctl reload apache2

or

sudo systemctl reload nginx

“`

If you are running a managed environment, a VPS with cPanel provides a GUI interface under SSL/TLS Manager where you can paste the certificate, private key, and CA bundle directly without touching configuration files manually.

Step 5: Renew or Replace an Expired Certificate

If the certificate has expired, there is no client-side workaround. The server must present a valid certificate.

For Let's Encrypt (Certbot):

“`bash

sudo certbot renew –dry-run

sudo certbot renew

sudo systemctl reload nginx # or apache2

“`

For manually managed certificates: Obtain a new certificate from your CA, upload it via your control panel, and ensure the new certificate's chain is complete. If you need a trusted certificate for a production domain, SSL Certificates from a recognized CA eliminate the self-signed certificate problem entirely.

Automate renewals: Let's Encrypt certificates expire every 90 days. Add a cron job or use systemd timers to automate renewal:

“`bash

0 3 * * * /usr/bin/certbot renew –quiet –post-hook "systemctl reload nginx"

“`

Step 6: Trust a Self-Signed Certificate for Internal Use

If you are running internal tooling, a development server, or a private network service where replacing the certificate is not feasible, you can add the self-signed certificate to the OS trust store.

Windows:

1. Export the certificate from the browser (click the warning > Certificate > Details > Copy to File).
2. Open `certmgr.msc`.
3. Navigate to Trusted Root Certification Authorities > Certificates.
4. Right-click > All Tasks > Import and import the certificate.

macOS:

“`bash

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.crt

“`

Linux (Debian/Ubuntu):

“`bash

sudo cp cert.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

“`

Important: Chrome on Linux and Windows uses the OS trust store for most purposes, but also maintains its own NSS database. If Chrome still rejects the cert after updating the OS store, import it directly via `chrome://settings/certificates`.

Step 7: Update the Browser and Operating System

An outdated browser may lack newer root CA certificates or may not support current TLS protocol versions (TLS 1.2 minimum is now required; TLS 1.3 is preferred).

Chrome: Navigate to `chrome://settings/help`. Chrome auto-updates; if an update is pending, it will install here.

Firefox: Navigate to Help > About Firefox. Firefox will check for and apply updates.

Operating System: On Windows, ensure Windows Update is current. On Linux servers, run:

“`bash

sudo apt update && sudo apt upgrade ca-certificates openssl

“`

This is particularly important for servers running older distributions where the CA bundle (`ca-certificates` package) has not been updated to include newer root CAs.

Step 8: Reset Network Stack and Flush DNS

Network-level misconfigurations, corrupted DNS caches, or stale Winsock entries can occasionally contribute to TLS negotiation failures.

Windows (run Command Prompt as Administrator):

“`cmd

netsh int ip reset

netsh winsock reset

ipconfig /release

ipconfig /renew

ipconfig /flushdns

“`

Restart the machine after running these commands.

macOS:

“`bash

sudo dscacheutil -flushcache

sudo killall -HUP mDNSResponder

“`

Linux:

“`bash

sudo systemd-resolve –flush-caches

or for systems using nscd:

sudo service nscd restart

“`

Step 9: Bypass the Warning (Testing Only)

This is strictly a diagnostic tool, not a solution. Use it only to confirm that the error is certificate-related and not a network or application issue, or when accessing a known-safe internal server during development.

Chrome: Click Advanced on the error page, then Proceed to [domain] (unsafe).

Firefox: Click Advanced, then Accept the Risk and Continue.

Never bypass this warning on sites handling authentication, payments, or personal data. The warning exists because the connection is genuinely unverified.

Verifying the Fix

After applying any server-side change, validate the result using these tools before declaring the issue resolved:

• SSL Labs SSL Test (`ssllabs.com/ssltest/`): Provides a full chain analysis, protocol support grade, and identifies specific configuration weaknesses.
• `openssl s_client`: Command-line verification that shows exactly what the server is presenting during the TLS handshake.
• `curl -vI https://yourdomain.com`: Quick check that shows TLS handshake details and certificate validation result.
• `whatsmychaincert.com`: Specifically diagnoses missing intermediate certificates.

Choosing the Right Hosting Infrastructure to Prevent Recurrence

Many certificate errors stem from infrastructure limitations rather than administrator error. Shared hosting environments sometimes restrict how certificate chains are configured or limit access to web server configuration files. If you are repeatedly encountering chain or renewal issues, migrating to a VPS Hosting environment gives you full control over your TLS stack — including the ability to configure Nginx or Apache directly, automate Certbot renewals, and install custom CA bundles.

For high-traffic or compliance-sensitive workloads where certificate management is critical, Dedicated Servers eliminate the multi-tenant variables that can complicate SSL configuration. If you are managing multiple domains or subdomains, a VPS Control Panel simplifies certificate deployment across all of them from a single interface.

Decision Matrix: Which Fix Applies to Your Situation

Practical Key-Takeaway Checklist

• Confirm whether the error is client-side (clock, cache, SSL inspection) or server-side (expired cert, missing intermediate) before taking any action.
• Run `openssl s_client -connect domain:443 -showcerts` as the first diagnostic step for any server-side investigation.
• Always concatenate the full certificate chain (end-entity + all intermediates) in your web server configuration.
• Automate certificate renewal with Certbot cron jobs or equivalent — manual renewal is a guaranteed path to future outages.
• After any certificate change, validate with SSL Labs before closing the incident.
• Never permanently disable antivirus SSL scanning; instead, configure exclusions or install the proxy CA certificate properly.
• On Linux servers, keep the `ca-certificates` and `openssl` packages updated to ensure the root store reflects current trusted CAs.
• Use `chrome://net-internals/#hsts` to clear HSTS cache entries when a domain's certificate has been legitimately changed and Chrome still refuses to connect.

Frequently Asked Questions

What is the difference between NET::ERR_CERT_AUTHORITY_INVALID and NET::ERR_CERT_COMMON_NAME_INVALID?

`ERR_CERT_AUTHORITY_INVALID` means the certificate's issuer is not trusted — the chain cannot be verified. `ERR_CERT_COMMON_NAME_INVALID` means the certificate is from a trusted CA but was issued for a different domain than the one being accessed. They require different fixes: the first requires a new certificate from a trusted CA or chain repair; the second requires a certificate reissued with the correct Subject Alternative Names.

Can NET::ERR_CERT_AUTHORITY_INVALID appear even with a valid, paid SSL certificate?

Yes. A paid certificate from a trusted CA will still trigger this error if the intermediate certificate is not included in the server's TLS response. The browser cannot always fetch missing intermediates automatically (AIA fetching is unreliable), so the chain must be explicitly configured on the server.

Why does this error appear only in Chrome but not Firefox?

Firefox maintains its own certificate trust store and also caches intermediate certificates from previous successful connections (a mechanism called AIA fetching with caching). Chrome relies more strictly on the OS trust store and the chain presented by the server. A missing intermediate that Firefox has cached from a prior session will still cause Chrome to fail.

Is it safe to click "Proceed anyway" on the NET::ERR_CERT_AUTHORITY_INVALID warning?

Only in controlled scenarios: accessing a known internal server, a local development environment, or a staging server you administer. On any public-facing site — especially those requiring login credentials, payment information, or personal data — proceeding is genuinely dangerous. The connection is unencrypted from a trust perspective, meaning any interceptor on the network path can read or modify traffic.

How do I prevent this error from recurring on my production server?

Automate certificate renewal (Certbot with a cron job or systemd timer), monitor certificate expiry with an external tool (UptimeRobot, Zabbix, or `ssl-cert-check`), always deploy the full certificate chain, and keep your server's NTP synchronization active. For environments where manual management is error-prone, consider a hosting platform with integrated certificate management — a VPS with cPanel handles AutoSSL renewals automatically across all hosted domains.