NET::ERR_CERT_AUTHORITY_INVALID means Chrome cannot build a certificate chain to an authority it trusts for the HTTPS connection. The cause may be a website's incomplete or unsuitable certificate chain, outdated trusted certificates on the device, or a network product that intercepts HTTPS. The warning alone does not tell you which one is responsible.

Do not enter passwords or payment details while the warning remains. Record the exact hostname and error, then check whether the problem follows the site, device, or network so the right administrator can fix it.

Check the Hostname and Certificate Details

Read the full address in Chrome and the exact error code. A misspelled hostname, a certificate name mismatch, and an expired certificate are separate issues even if each produces a privacy warning. If Chrome offers certificate details, note the certificate's subject, issuer, and chain information. An unfamiliar issuer is not proof of an attack: a workplace proxy can present a different issuer, but the organization must verify that the proxy is authorized.

A certificate authority (CA) signs certificates used to authenticate websites. Chrome needs a valid chain from the site's certificate, through any required intermediates, to a trusted root. A trusted chain is only one requirement; Chrome also checks the hostname, validity dates, and other security conditions.

If a public site serves an incomplete chain, some clients can fail while others appear to work because their trust stores and cached intermediates differ. The site owner should verify the chain from an external client rather than assuming one successful browser test proves the deployment is correct.

Compare Devices and Networks

Try the same HTTPS address in an up-to-date browser on another device you control. If possible, try that address over another trusted network, such as your own mobile connection. Keep the address identical in both tests.

If many unrelated HTTPS sites fail on one device, check that device and its security software first. If the same site fails on several devices with up-to-date browsers and on different networks, send the results to the site owner.

If the warning appears only on one corporate or school network, a proxy or HTTPS-inspection gateway may be changing the certificate that Chrome sees. Record which device and network combinations worked, which failed, the time of each test, and the issuer shown if available. These comparisons are clues rather than a diagnosis: a site can have a chain problem that affects one device family, and a filtering product can apply rules to only one domain.

If a public Wi-Fi network requires sign-in, use the network's official sign-in page before retrying the HTTPS site. A portal that intercepts an initial request can trigger a certificate warning. Ask the network operator if you cannot find the official sign-in page; do not type your website password into a page that merely resembles the intended site.

Check Local Time and Updates

Check the device's date, time, and time zone. A wrong clock often produces a date-specific certificate error rather than this authority code, so read the error displayed after correcting the clock.

Install available Chrome and operating system updates. On Windows or macOS, open Chrome's More menu, select Help, and open About Google Chrome to check for an update. Relaunch Chrome if prompted. On Linux, update Chrome through your package manager; on a Chromebook, update ChromeOS.

Chrome maintains its own list of trusted root certificates, called the Chrome Root Store, on Windows, macOS, ChromeOS, Linux, and Android. Updating only the operating system does not necessarily update that list; Chrome on iOS instead relies on Apple's platform. If an old device cannot run a supported browser or operating system, use a supported device for sensitive browsing and arrange an upgrade.

Check HTTPS Inspection and Trusted Certificates

On a managed device, send the exact error and comparison results to IT. An HTTPS-inspection proxy presents certificates that the organization's devices must be configured to trust. A missing or incorrectly deployed corporate certificate can cause this warning. Ask the administrator to check the proxy's certificate chain and the affected browser's trust settings, rather than installing a certificate from a website prompt yourself.

On a personal device, review whether a security suite recently changed its HTTPS scanning or certificate settings. If the problem began after that change, ask the software vendor to correct the configuration or provide an update. Avoid turning off protection globally just to reach one site. Adding an unknown root certificate is also unsafe because it can allow certificates for many sites to be trusted, far beyond the page that showed the error.

What the Website Owner Should Fix

If the site fails in up-to-date browsers on different devices and networks, inspect the certificate and complete intermediate chain served by the browser-facing HTTPS endpoint. That endpoint might be a content delivery network (CDN), load balancer, reverse proxy, or web server. The certificate must match the hostname and lead to a root trusted by the intended browsers. Installing a new certificate on the origin alone will not fix a front-end that continues to serve an old or incomplete chain.

Review recent certificate renewals, hosting changes, and chain files. Use the intermediate certificates supplied for the issued site certificate, following the host's configuration instructions. If the issuer is not trusted by the intended browsers, obtain a certificate from a suitable CA instead of asking visitors to change their trust settings. After updating the certificate or chain, test the public hostname again using the same type of browser and device that originally failed.

Retest the Original HTTPS Address

After the administrator or site owner reports a fix, revisit the original HTTPS address in an updated browser. Confirm that Chrome no longer shows the warning and that the hostname is the one you intended. If Chrome still shows a warning, send back the exact code and any changed issuer information. A successful page load on another hostname does not prove the affected site is fixed.

Some sites enforce HTTP Strict Transport Security (HSTS), which requires HTTPS and prevents users from clicking through certificate errors. Removing that protection does not repair the certificate problem. If the error remains unresolved, contact the organization through another trusted channel instead of using a browser bypass or an unencrypted login page.