How to Fix the NET::ERR_CERT_AUTHORITY_INVALID Error

When Chrome blocks a page with NET::ERR_CERT_AUTHORITY_INVALID, it is saying something narrower than “the certificate is bad”. The certificate may be perfectly valid: issued by a real Certificate Authority, matching the domain, and still well inside its validity period. What failed is the chain. Chrome could not link that certificate back to a root certificate it already trusts, so it has no way to confirm who vouched for the site.

This guide explains what breaks that chain, how to identify which case you are in before you change anything, and how to fix it from both sides: as the website owner, and as a visitor who cannot reach a site.

Quick answer:

NET::ERR_CERT_AUTHORITY_INVALID means Chrome could not build a chain of trust from the certificate a site presented back to a root certificate in its trust store. It is not an expiry error, expiry is a separate code called NET::ERR_CERT_DATE_INVALID. The most common cause is a server that sends only its leaf certificate and omits the intermediate certificate, so the fix is on the server: install the full chain (leaf first, then intermediate), test the configuration, and reload the web server. When only one device sees the error, the usual cause is software on that device re-signing traffic with its own root, such as antivirus HTTPS scanning or a corporate TLS-inspecting proxy.

What NET::ERR_CERT_AUTHORITY_INVALID Actually Means

Browsers do not trust certificates one by one. They trust a small set of root certificates shipped in a trust store, and everything else has to connect back to one of them. The check runs during the TLS handshake, before any page content is exchanged. A normal HTTPS certificate is validated in three links:

1. The leaf certificate, issued for your domain, is the one your server presents.
2. The intermediate certificate signed that leaf. Certificate Authorities issue from intermediates rather than directly from their roots, so this link is almost always present in a real chain.
3. The root certificate signed the intermediate, and the browser already has it.

Chromium tracks this failure internally as error -202, described in its source as a certificate “signed by an authority we don’t trust”. Chromium documents three situations that produce it:

• An attacker substituted the real certificate for one signed by an issuer the browser has no reason to trust.
• The server operator holds a legitimate certificate from a CA the browser does not know about.
• The server is presenting a self-signed certificate.

Notice what is absent from that list: nothing about expiry dates, nothing about the visitor’s cache, and nothing about the clock on the visitor’s computer. Chrome has separate codes for those. The single question behind this error is whether the browser can identify the issuer and follow it up to a trusted root.

Other browsers report the same condition in their own wording. If you support users across browsers, these are the equivalents worth recognizing:

• Chrome, Edge, Brave and Opera (all built on Chromium) show NET::ERR_CERT_AUTHORITY_INVALID under the Your connection is not private headline.
• Firefox reports SEC_ERROR_UNKNOWN_ISSUER, which is the same missing-issuer problem seen through Mozilla’s certificate verifier.
• Safari prints no code and says instead that it cannot verify the identity of the website.

Because the mechanism is identical, a server-side fix in this guide resolves the Firefox and Safari versions at the same time. A fix that only works in one browser is a sign you treated a symptom.

Check You Are Not Looking at NET::ERR_CERT_DATE_INVALID

Chrome’s certificate warnings all look alike, so it is easy to start fixing the wrong thing. Read the code printed under the warning text and match it against this list before going further:

• NET::ERR_CERT_AUTHORITY_INVALID (internally -202): the issuer is not trusted, or the browser cannot work out who the issuer is. That is this page.
• NET::ERR_CERT_DATE_INVALID (-201): the certificate has expired or is not yet valid, or the device clock is wrong. See how to fix NET::ERR_CERT_DATE_INVALID.
• NET::ERR_CERT_COMMON_NAME_INVALID (-200): the certificate is trusted but was issued for a different hostname. See how to fix ERR_CERT_COMMON_NAME_INVALID.

An expired certificate does not produce NET::ERR_CERT_AUTHORITY_INVALID, and renewing a certificate will not clear it. If you are on this page because a certificate lapsed, the date error is the one to read.

Diagnose It First: Find Out Who Issued the Certificate

Every cause below leaves a different fingerprint in the Issuer field of the certificate the browser received. Two minutes of checking tells you which branch to take and saves you from changing server configuration to fix something installed on your own laptop.

1. Read the Issuer in Chrome’s certificate viewer

Chrome will still show you the rejected certificate. From the warning page:

1. Click the icon to the left of the address bar (the sliders icon in current Chrome versions, a padlock in older ones).
2. Open the connection details, then choose the certificate entry to open the certificate viewer.
3. On the General tab, read Issued By. On the Details tab, the Issuer field shows the same information in full.

What you read there maps directly onto a cause:

• A public CA you recognize (Sectigo, DigiCert, Let’s Encrypt, GlobalSign), yet the chain still fails: the server is very likely not sending the intermediate certificate.
• The issuer name equals the subject name: the certificate is self-signed.
• Your antivirus vendor, your firewall vendor, or a product name you recognize from your own device: local HTTPS inspection is re-signing the traffic.
• Your employer’s or school’s name: a TLS-inspecting proxy on the network whose root is not installed on your device.
• An internal CA name belonging to the organization that runs the site: a private CA whose root was never distributed to this machine.

2. Inspect the chain the server actually sends

The browser view can be misleading, because Chrome on the desktop repairs some broken chains on its own (explained in the next section). To see exactly what your server transmits, ask it directly with the OpenSSL utility:

openssl s_client -connect example.com:443 -servername example.com -showcerts

The -servername flag sends your hostname via SNI, which is what a real browser does. Since OpenSSL 1.1.1 the tool fills SNI in automatically from the host you gave to -connect, so on a current build the flag is explicit rather than strictly required. It still matters on older OpenSSL versions, and whenever you connect to a raw IP address and have to state the name yourself. Two parts of the output matter. At the top, the certificate chain lists every certificate the server sent, with s: for subject and i: for issuer. A healthy chain looks like this:

Certificate chain
 0 s:CN = example.com
   i:C = US, O = Let's Encrypt, CN = R11
 1 s:C = US, O = Let's Encrypt, CN = R11
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1

Each certificate’s issuer is the subject of the next one down, so the chain is continuous. A server missing its intermediate sends only certificate 0, and the last line of the output confirms it:

Certificate chain
 0 s:CN = example.com
   i:C = US, O = Let's Encrypt, CN = R11

Verify return code: 21 (unable to verify the first certificate)

Verify return code: 21 is the signature of an incomplete chain and the single most useful line on this page. A correctly configured server returns Verify return code: 0 (ok). To read just that line without the command waiting for input, run:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | grep "Verify return code"

One caveat if you test from a Mac: the openssl command bundled with macOS is LibreSSL, not OpenSSL, and its chain diagnostics are not equivalent. It reports a missing intermediate as 21 just as OpenSSL does, but it stops at depth 0 and reports that same 21 when the intermediate is present and expired, where OpenSSL names the failing certificate and returns 10, so a Mac result can send you after the wrong fault. Run openssl version first. If it reports LibreSSL, test from a Linux host, install OpenSSL through Homebrew, or use the external scan below.

3. Confirm with an external scan

Run the domain through our free SSL Checker. It connects from outside your network, reports the chain the server presents, and flags a missing intermediate explicitly. That external view matters: a chain can look complete on the server, where the intermediate sits in the local certificate store, and still be incomplete for everyone else, because the server never puts it on the wire.

How to Fix NET::ERR_CERT_AUTHORITY_INVALID as a Website Owner

The causes below are ordered by how often they turn out to be the answer. If your diagnostic showed Verify return code: 21, start at the first one and you will probably be finished there.

1. A missing or misordered intermediate certificate

This is the dominant cause of the error and the one most often overlooked, because nothing about it looks wrong. Your certificate is genuine, unexpired, and issued for the right domain. The server simply never sends the intermediate that connects it to the CA’s root, so the browser receives a certificate whose issuer it cannot locate.

It usually happens when the CA delivers several files and only the leaf certificate gets installed. The intermediate arrives as a separate file, often named as a CA bundle or chain file, and it is easy to skip.

Why it works for you and not for your users

Here is the detail that keeps this cause hidden. Certificates carry an Authority Information Access extension, which includes a URL where the issuing intermediate can be downloaded. Chrome on desktop, along with Edge and Safari, will follow that URL and fetch the missing intermediate on its own, quietly repairing the broken chain.

Mobile is where this usually surfaces first. The Android platform validator that native apps rely on performs no AIA fetching at all. Chrome and WebView on Android do attempt it, but only on a best-effort basis. Android does cache intermediates it has already seen, which can hide a broken chain for a while, but that cache is held in memory inside each app and disappears when the app restarts. Command-line tools, API clients, and Java applications generally do not fetch at all. Firefox takes a third route, downloading a list of known intermediates in advance rather than fetching them on demand. The result is a site that loads normally on the owner’s desktop while mobile visitors are blocked, payment callbacks fail, and integrations report certificate errors. When a site “works for me but not for them”, an incomplete chain is the first thing to check. Never treat any of these repair mechanisms as a fix: they are fallbacks, none of them is guaranteed to run, and a large share of clients do not implement them at all.

Build the full chain file

Concatenate your certificate and the intermediate into one file. Order is not optional: the leaf comes first, then each intermediate, working up toward the root. The root itself can be left out, since clients that trust it already have it.

cat example_com.crt example_com.ca-bundle > fullchain.crt

Verify the order before deploying, because a reversed file is a common cause of a “fix” that changes nothing:

openssl crl2pkcs7 -nocrl -certfile fullchain.crt | openssl pkcs7 -print_certs -noout

Your domain must be listed first, and each certificate’s issuer must match the subject of the one after it.

Point nginx at the full chain

Nginx has no separate directive for the chain. The file given to ssl_certificate must already contain the leaf and the intermediates:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/ssl/certs/fullchain.crt;
    ssl_certificate_key /etc/ssl/private/example_com.key;
}

Test the configuration before applying it, then reload:

sudo nginx -t
sudo systemctl reload nginx

Point Apache at the full chain

On Apache 2.4.8 and later, SSLCertificateFile reads intermediates from the same file, and the old SSLCertificateChainFile directive is obsolete. If your configuration still uses it, move the intermediates into the chain file and delete the directive:

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on

    SSLCertificateFile    /etc/ssl/certs/fullchain.crt
    SSLCertificateKeyFile /etc/ssl/private/example_com.key
</VirtualHost>

Test and reload:

sudo apachectl configtest
sudo systemctl reload apache2

On Windows and IIS the chain is not configured in the site binding at all. Import the intermediate into the local machine’s Intermediate Certification Authorities store, where IIS picks it up automatically when it builds the chain. On a load balancer, CDN, or reverse proxy, the certificate must be installed on whichever device terminates TLS, which is often not the origin web server.

After reloading, run the OpenSSL check again from a machine outside your network. Certificate 1 should now appear in the chain and the verify code should read 0. A related failure worth knowing about: if the intermediate is present but past its own expiry date, the chain breaks again and Chrome usually reports a date error instead. See our guide on the expired intermediate SSL certificate.

2. A self-signed certificate

Anyone can create a self-signed certificate and become their own Certificate Authority. The problem is that no browser trusts one, because there is no independent party attesting to who you are. In the certificate viewer it is unmistakable: the issuer and the subject are the same name.

Self-signed certificates are reasonable in testing environments and on internal systems where browser warnings do not matter. On a public site they cause exactly this error for every visitor, and there is no configuration change that suppresses it. The fix is to replace it with a certificate from a publicly trusted CA. If you are using a self-signed certificate on a staging server that occasionally gets shared, expect the warning to keep coming back until you issue a real certificate for that hostname.

3. Your CA was distrusted or removed from the root store

A certificate that worked yesterday can fail today without anything changing on your server, because the trust decision lives in the browser, not in your configuration. When a CA stops meeting root program requirements, browsers remove or restrict it, and every certificate that chains to the affected root starts failing.

This is not hypothetical. Chrome stopped trusting certificates issued from several Entrust roots where the certificate timestamp is later than November 11, 2024, with Apple and Mozilla following on their own dates. The same thing happened earlier to the legacy Symantec roots, which produced its own Chrome code, NET::ERR_CERT_SYMANTEC_LEGACY.

Two signals point here: the error appeared without a deployment, and it appeared in some browsers before others, because vendors set different cut-off dates. There is no server-side workaround. Reissue the certificate through a CA in good standing, install the new chain, and reload. If your certificate is affected by a distrust action, your CA will normally reissue at no charge.

4. A private or internal CA whose root was never distributed

Organizations often run their own CA for intranet sites, staging environments, and internal APIs. That works only on devices where the organization’s root certificate has been installed. Any device without it sees a certificate signed by an authority it has never heard of, which is precisely this error.

The symptom is a site that loads for staff on managed laptops and fails on personal phones, contractor machines, or a newly imaged workstation. The fix is distribution, not certificate replacement: push the internal root to managed devices through Group Policy on Windows, or through your MDM profile on macOS, iOS and Android. Chrome uses its own root store but still honors roots an administrator has explicitly trusted on the device, so a properly deployed enterprise root works.

If the service also has to be reachable by people outside the organization, an internal CA is the wrong tool. Anything the public touches needs a publicly trusted SSL certificate.

5. The wrong virtual host is answering the request

One IP address can host many sites, and the server decides which certificate to present based on the hostname the client sends via SNI. When that lookup misses, the server falls back to its default virtual host and serves whatever certificate is configured there.

On a fresh install that default is frequently the self-signed placeholder shipped with the distribution or the control panel, which is why the error can appear on a domain whose certificate is installed and valid. You are not seeing your certificate at all, you are seeing someone else’s default. Confirm it by comparing the subject that OpenSSL returns against the domain you requested. If the fallback happens to serve a valid certificate for a different hostname, Chrome reports ERR_CERT_COMMON_NAME_INVALID instead, which is a useful clue that you are in this case rather than the previous ones.

Check that a virtual host block exists for the exact hostname, including the www and non-www forms you serve, that it listens on port 443, and that it points at the correct certificate. Older clients that do not send SNI at all always receive the default virtual host, so a site that must support them needs a dedicated IP address.

How to Fix NET::ERR_CERT_AUTHORITY_INVALID as a Website Visitor

If the error appears on well-known sites, or on one device while other devices on the same network load the site normally, the cause is local to that device. Start by narrowing it down: open the same site on a phone using mobile data rather than Wi-Fi. If it loads there and fails on your computer, something on the computer or the local network is intercepting the connection.

Clearing your browser cache and removing extensions will not help here. Neither one can change which certificate a server presents or which roots your system trusts. The checks below address causes that genuinely produce this error.

1. Turn off your security software’s HTTPS scanning

Many antivirus and internet security products include a feature variously called HTTPS scanning, SSL/TLS filtering, encrypted web scan, or web shield. To inspect encrypted traffic, the product terminates the TLS connection itself, decrypts and scans the content, then re-encrypts it using a root certificate it installed on your machine during setup. Your browser is not talking to the website’s certificate any more, it is talking to one your antivirus generated seconds ago.

Normally the installer adds that root to the system trust store and nothing looks unusual. When the installation is incomplete, the root is removed by a cleanup tool, a browser profile is not covered, or the feature interacts badly with a site, the re-signed certificate is rejected and you get this error. Confirm it in the certificate viewer: if Issued By names your security product rather than a public CA, this is your cause.

Turn off only the HTTPS or SSL scanning component, not the antivirus itself. The setting lives under the web or network protection area of the product, and disabling it leaves file, email, and behavioral protection running. Reload the page. If the error clears, either leave HTTPS scanning off or reinstall the product so its root certificate is registered correctly.

Do not disable your antivirus entirely to test this. It removes protection you still need and it does not isolate the cause any better than switching off the one feature responsible.

2. Check whether you are behind a TLS-inspecting proxy

Corporate, school, and guest networks frequently route traffic through a proxy or firewall that inspects HTTPS the same way antivirus software does, by re-signing every connection with the organization’s own root. Managed devices receive that root automatically, so employees notice nothing. A personal laptop or a visitor’s phone on the same network has never seen it and gets blocked on every HTTPS site.

The signature is an issuer named after the organization or its security vendor, and errors on most sites at once rather than a single one. On a device your employer manages, ask IT to deploy the root certificate. On a personal device, use a different network, or mobile data, rather than installing a corporate root yourself: installing one lets whoever controls it read your encrypted traffic on that machine, including your own accounts.

3. Update your operating system and browser

Root certificates are shipped with your operating system and browser, and they change over time as CAs add new roots and retire old ones. A device that has not been updated for years carries a stale trust store, so certificates chaining to a newer root fail even though the site is configured correctly. This is common on old Android phones and on desktops kept on an operating system that no longer receives updates.

Install pending operating system updates, update Chrome to the current version, and restart. If the device cannot be updated any further, the trust store cannot be refreshed either, and that device will keep failing on a growing number of sites.

4. Treat an unexplained warning as a real one

Chrome offers an Advanced link with a proceed option on the warning page. On a development server you control, using it is a reasonable shortcut. Anywhere else, it is worth pausing.

This error is the one browsers raise when a connection may be intercepted, and clicking through sends your traffic to whoever presented the certificate. If a bank, a mail service, or a shop triggers it and you cannot explain the issuer, do not proceed and do not enter credentials. Adware and malware sometimes install their own root certificate to intercept traffic, so an issuer you do not recognize on a public site is worth investigating with a malware scan rather than dismissing. The safe response is to reach the site over a different network and report the problem to its operator.

Frequently Asked Questions

For more SSL error troubleshooting, check our detailed tutorials about fixing different SSL errors.