Security & access
NET::ERR_CERT_AUTHORITY_INVALID: locate and fix the trust failure
Separate website certificate problems from device and network trust issues, then verify the certificate visitors receive.
NET::ERR_CERT_AUTHORITY_INVALID means Chrome could not establish trust in the certificate authority chain for the connection it received. The problem may be the website’s certificate setup or something on the device or network changing that connection.
Do not ask visitors to bypass the warning to log in or pay. Identify the certificate actually presented, then fix the layer responsible.
Work out the scope
| Where it happens | Investigation path |
|---|---|
| One website, across devices and networks | Its public certificate, chain, hostname routing, and TLS configuration. |
| Many websites on one device | Browser and OS updates, local trust configuration, and security software. |
| Only on a work network | Managed HTTPS inspection and the organization’s certificate deployment. |
| Only after a hosting or proxy change | Which endpoint now terminates HTTPS and which certificate it presents. |
Record the exact error code, URL, browser version, and time. Compare from a separate trusted device and network when available. An expiry error or hostname mismatch can appear on a similar warning page but calls for a different diagnosis.
If you own the website, inspect the served chain
Check the certificate issuer, covered hostnames, validity, and intermediate chain from the public endpoint. The certificate installed in a hosting panel may not be the one visitors receive if a proxy, load balancer, or another server sits in front.
Let’s Encrypt’s compatibility guidance identifies an incorrectly supplied chain as a common cause of failures on otherwise compatible modern platforms. Install the supported full chain through the hosting or web-server configuration process, rather than adding an arbitrary certificate to each visitor’s device.
Check all intended hostnames and active endpoints. A migration can leave an old IPv6 destination or a second frontend serving different TLS configuration. Confirm certificate renewal automation after correcting the immediate problem.
Distinguish public certificates from origin certificates
A certificate intended for a private proxy-to-origin connection may not be trusted by public browsers. If a site previously worked behind a proxy and the origin becomes directly accessible, the browser can receive a different certificate than before.
For Cloudflare specifically, its Origin CA documentation describes certificates for securing the connection between Cloudflare and the origin. Use a publicly trusted certificate when browsers need to connect directly, and verify the complete HTTPS path when changing proxy configuration.
If it is limited to a device or network
Update the browser and operating system, and confirm the device’s clock is accurate. Check whether the network requires an ordinary captive-portal sign-in. Avoid entering sensitive website credentials while the certificate warning remains unresolved.
Google’s Chrome troubleshooting guide notes that enterprise HTTPS-inspection systems can produce this error when their required certificate is missing. On a managed computer, ask the administrator to verify the organization’s configuration. Do not install an unknown root certificate sent by an unverified support contact.
Confirm the repair from the visitor’s path
Revisit the affected URL in a fresh connection and check a second device. Include both the main domain and relevant subdomains. If a scanner sees the correct chain but a user still receives a different issuer, compare that user’s network path instead of repeatedly reissuing the site certificate.
Keep the original error, certificate details, affected endpoint, and change made in the support record. This distinguishes a lasting repair from a temporary success caused by reaching a different server.