Windows · high · Applications & Microsoft 365

Certificate errors on every site — NET::ERR_CERT_AUTHORITY_INVALID

Something between the browser and the site is presenting its own certificate, or the machine's clock and trust store are wrong.

What you see

Every HTTPS site warns, including well-known ones. Applications that use HTTPS fail at the same time with less helpful errors.

What is actually wrong

A wrong system clock invalidates every certificate at once. Beyond that: a corporate or antivirus TLS inspection proxy whose root is not trusted, an expired root certificate on a machine that has not updated in years, or malware that has installed its own root.

Codes and articles

NET::ERR_CERT_AUTHORITY_INVALIDNET::ERR_CERT_DATE_INVALIDSEC_ERROR_UNKNOWN_ISSUER0x800B0109ERR_CERT_COMMON_NAME_INVALID

Fixes (3)

Fix the clock and the reason it drifted

Elevated PowerShell15 minuteslow riskreversible

The date or time is wrong. This alone breaks every certificate on the machine.

Check the time, time zone and source.
PowerShell
```
Get-Datew32tm /query /status
```

Set the time service to sync and force a resync.

PowerShell

Set-Service w32time -StartupType AutomaticStart-Service w32timew32tm /resync /force

On a domain machine, do not point it at an internet source — it must follow the domain hierarchy or Kerberos breaks.
PowerShell
```
w32tm /config /syncfromflags:domhier /updateRestart-Service w32time
```
Kerberos rejects a ticket with more than five minutes of skew. Setting a domain member to sync from time.windows.com creates an inconsistency that shows up later as sign-in failures nobody connects to this fix.
If the clock resets every boot, the CMOS battery is flat. Replace it — a machine that loses the time at every power-off will keep doing this.

Confirm it workedThe time is correct and stays correct after a full power-off overnight.

PowerShell

w32tm /query /status | Select-String 'Source|Last Successful'

If you need to undo itTime settings can be set manually again if required.

Inspect the trust store for what should not be there

Elevated PowerShell25 minuteshigh riskreversible

The clock is right. Look at what the machine trusts before changing anything.

Look at the certificate the browser is actually being offered. Click the warning, view the certificate, and read the issuer — that name is the answer.
If the issuer is your antivirus or your employer's firewall, this is TLS inspection and expected. If it is a name you do not recognise, treat the machine as compromised and act accordingly.

List roots that are not from Microsoft's program, sorted by when they were installed.

PowerShell

Get-ChildItem Cert:\LocalMachine\Root |  Sort-Object NotBefore -Descending |  Select-Object -First 25 Subject,Issuer,NotAfter,Thumbprint |  Format-Table -Wrap

Check the per-user store as well — malware frequently installs there because it needs no elevation.

PowerShell

Get-ChildItem Cert:\CurrentUser\Root | Where-Object { $_.Subject -ne $_.Issuer -or $_.NotBefore -gt (Get-Date).AddYears(-2) } | Format-Table Subject,NotAfter,Thumbprint

Remove a root only when you are certain what it is. Removing a legitimate corporate root breaks every internal site on the machine.
PowerShell
```
Remove-Item -Path 'Cert:\CurrentUser\Root\THUMBPRINT' -Force
```
Refresh the trusted root list from Microsoft on a machine that has been offline a long time.
PowerShell
```
certutil -generateSSTFromWU C:\roots.sstcertutil -addstore -f Root C:\roots.sst
```

Confirm it workedWell-known sites load without a warning and the corporate sites still work.

PowerShell

Test-NetConnection www.microsoft.com -Port 443 -InformationLevel Quiet

If you need to undo itExport any certificate with Export-Certificate before removing it, and re-import with Import-Certificate.

Trust the inspection proxy properly, or exempt what breaks

Elevated PowerShell30 minutesmedium riskreversible

The issuer is a known firewall or antivirus, and only some things break.

Deploy the inspection root to the machine's trusted root store — by Group Policy on a domain, or by hand on a standalone machine.
PowerShell
```
Import-Certificate -FilePath C:\corp-root.cer -CertStoreLocation Cert:\LocalMachine\Root
```
Remember that several applications do not use the Windows trust store at all. Firefox has its own, and Java, Node.js, Python and git each carry their own bundle.
This is why "it works in Edge but not in our application" is so common with inspection proxies. Each of those needs the root adding separately, or the endpoint exempting from inspection.
Exempt certificate-pinned services from inspection on the firewall — Microsoft 365, Windows Update and most banking sites will fail no matter what is trusted, because they check for exactly the certificate they expect.
Document which endpoints are exempt so the next fault is quicker to place.

Confirm it workedBrowsers and the affected applications both connect without warnings.

If you need to undo itRemove the imported root with Remove-Item from the certificate store.

Related faults

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.