NET::ERR_CERT_AUTHORITY_INVALID in Chrome
Separate one untrusted site certificate from a network or device problem. Check the scope without bypassing the warning or installing unknown certificates.
Try this first
1 quick checks · ~5 min
Find your situation
See all the clues. Choose the one that matches what you observe.
Only one site fails
Investigate the site’s certificate path before changing the system.
You are using public Wi-Fi
Complete only the network’s legitimate sign-in.
Many HTTPS sites fail
Compare profile, network, and device software.
The device or network is managed
Proxy certificate deployment belongs with the administrator.
Diagnostic signals
- ObservationIt works in Incognito
- This points toward session or extension differences; Incognito does not repair certificates or certify a site as safe.
Step-by-step solutions
Check whether one or several sites fail
Scope determines whether to investigate the site or the environment shared by connections.
Record the exact code and try two known HTTPS sites without proceeding through warnings. Do not enter credentials or payment information on the blocked page. Note the network and device you are using.
If only one fails, follow the site branch. If several fail, check the portal first on public Wi-Fi; on a work or school device, contact the administrator before changing certificates or protection.
Keep the block when the problem is limited to one site
A comparison narrows the problem without making unsafe access a test.
Check the typed address and, if another device and authorized network are available, compare the same site without bypassing warnings. A shared failure strengthens the site path; working elsewhere does not rule out network or trust differences on the first device.
Contact the site owner through a known channel. Do not install a certificate offered through the error page just to gain access. If other sites also start failing, switch to the multiple-site branch.
Complete legitimate public Wi-Fi sign-in
A network requiring sign-in can interfere before you reach the requested site.
Use the network sign-in notification or ask its operator for the portal address. Do not give your email or banking password to a screen claiming to provide Wi-Fi access, or install certificates to sign in.
After legitimate sign-in, retry the original site. If the error remains, do not repeat login: compare an authorized trusted network and continue according to the observed scope.
Compare Incognito and review device changes
The comparison isolates differences rather than bypassing the warning.
Open the same site in Incognito. If it works there, review extensions that do not run in that mode, disabling one suspect at a time and comparing again in the normal window. Preserve managed-device restrictions.
If Incognito also fails, check supported system updates and recent network or security-software changes. An error limited to one network or HTTPS protection product points toward that layer’s owner; it does not justify leaving protection disabled.
Ask the security-software vendor about its HTTPS inspection. This guide does not require disabling antivirus to browse or independently installing trust roots.
Escalate managed HTTPS inspection
A proxy may present certificates whose trust must be deployed by the organization.
Tell IT the code, affected sites, and whether it changes outside the corporate network, if that comparison is authorized. Google identifies missing or incorrectly installed proxy certificates as one cause of this error.
Stop local modifications: the administrator needs to check the proxy and trust deployment. Do not download certificates from forums or try to bypass policies.
Still not working?
If it persists, give the site owner, IT, or security vendor the scope and comparisons. Without an explanation for the untrusted chain, preserve the block; do not treat the warning as an obstacle to bypass.
Sources
Documentation behind this guide. Editorial recommendations are identified separately.
Source review: . A documentation review, not a physical hardware test.