NET::ERR_CERT_AUTHORITY_INVALID (Untrusted Certificate)

What this error means & how to recognize it

• Chrome or another Chromium-based browser displays NET::ERR_CERT_AUTHORITY_INVALID instead of loading the HTTPS page normally.
• The browser identifies the connection or certificate as untrusted and may show an advanced warning screen.
• Certificate details show an unknown issuer, a self-signed certificate, or a broken or incomplete certification path.
• The error affects one website while other HTTPS sites work, or it affects many sites when a local security product or network proxy is involved.
• The website name may appear correct even though the certificate is not trusted, distinguishing this error from a hostname-mismatch warning.

Root causes, ordered by likelihood

1. Self-signed or privately issued certificate: The website certificate was not issued by a certificate authority trusted by the browser or operating system. This may be intentional on an internal development site but is unexpected for most public websites.
2. Missing intermediate certificate: The server sends its leaf certificate without the intermediate certificate needed to connect it to a trusted root. Some clients may have the missing certificate cached, while others will reject the chain.
3. Corporate, school, hotel, or other HTTPS inspection: A proxy or security appliance may replace the website certificate with one issued by a local organizational authority. The warning appears when that authority is missing, damaged, unexpected, or incorrectly deployed.
4. Antivirus or endpoint HTTPS scanning: Security software may inspect encrypted traffic and issue local certificates. A damaged installation or untrusted local certificate can cause the warning.
5. Incorrect date, time, or time zone: An incorrect device clock can make certificate validity dates appear incorrect and interfere with validation.
6. Outdated or damaged trust store: The operating system or browser may lack a required trusted root certificate, or its certificate database may be outdated or corrupted.
7. Captive portal or network interference: A public network may redirect traffic to a sign-in page or otherwise interfere with the expected HTTPS connection.

How to fix it

1. Do not bypass the warning yet

Do not enter passwords, payment details, or other sensitive information on a page showing this error. Avoid proceeding if the site is unfamiliar or the warning appears on a sensitive service. Bypassing the warning can hide an interception or incorrectly configured certificate.

2. Determine whether the problem is isolated

• Open several other well-known HTTPS websites.
• Test the affected site in a private window or another browser.
• If only one site fails, its certificate or server-delivered chain is more likely to be the cause.
• If many sites fail only on one network, investigate a proxy, HTTPS inspection, antivirus filtering, or captive portal.
• If the same site fails across different devices and networks, report the problem to the website owner instead of repeatedly changing local security settings.

3. Inspect the certificate details

Open the browser’s certificate or connection-details panel on the warning page. Note:

• the certificate subject and hostname coverage;
• the issuer;
• the validity start and expiration dates;
• whether the certification path is broken or incomplete;
• whether the issuer appears to belong to a company, school, antivirus product, or local proxy.

A matching hostname does not prove that the certificate is trusted. If the issuer is unknown, privately issued, or unexpected, do not install it merely to remove the warning.

4. Verify the device clock

Confirm the device’s date, time, and time zone. Enable automatic time settings where appropriate, then close and reopen the browser and test again. Do not deliberately change the clock to force a certificate to appear valid.

5. Check for a captive portal

On a public network, open a non-sensitive website and complete the network’s normal sign-in or terms page if one appears. Reconnect to the HTTPS site afterward. Never submit credentials on a certificate warning page just to complete a network login; use the network’s normal portal flow or ask its operator for assistance.

6. Investigate proxy and security software

If the certificate issuer names a corporate proxy, school network, antivirus product, or endpoint security tool:

• confirm whether HTTPS inspection is expected on that network;
• ask the administrator whether the organization’s root certificate should be installed through its approved device-management process;
• update or repair the security product if it is your own software;
• test from a trusted network only when permitted by your organization’s policy.

Do not download a root certificate from an unverified website. Installing a root certificate gives its holder broad ability to make certificates appear trusted.

7. If you manage the website, correct the certificate chain

Confirm that the certificate:

• covers the requested hostname;
• is within its validity period;
• is issued by an authority trusted by intended clients; and
• is accompanied by the required intermediate certificate or certificates from the server.

Configure the server to send the complete chain rather than relying on each client to find missing intermediates. Re-test after deployment from multiple browsers, devices, and networks. A public website should not use a self-signed or private certificate unless every intended client is deliberately configured to trust its issuing authority.

8. Refresh local software only when evidence points to the device

Install pending operating-system and browser updates through their normal update mechanisms. If one browser alone is affected, review its proxy and certificate settings and test with a clean profile. If one device alone is affected, have its administrator inspect the local trust store and security software. Avoid deleting certificates or disabling certificate validation without knowing which application or organization installed them.

Prevention & how to verify the fix

• Keep the operating system, browser, and endpoint security software updated.
• Use automatic date, time, and time-zone settings where appropriate.
• Install organization-managed root certificates only through an approved administrator or device-management process.
• Treat unexpected certificate warnings on public networks as security signals, not routine prompts to bypass.
• Website administrators should deploy a certificate for the correct hostname and send the complete required intermediate chain.
• Avoid downloading certificate files or disabling HTTPS checks based on unofficial instructions.

Frequently asked questions