Fix 0x800B010A Certificate Chain Error – Real Fix

You're hitting 0x800B010A and it's a headache

I get it. You're trying to access a site or run a tool and Windows throws CERT_E_CHAINING (0x800B010A) – "A certificate chain could not be built to a trusted root authority." It's cryptic, it stops you cold, and it usually shows up at the worst time. I've seen this on Windows 10 Pro, Windows Server 2019, and even in Citrix environments. The culprit here is almost always a missing or corrupted root certificate, or something intercepting your HTTPS traffic.

The direct fix (works 90% of the time)

Update your root certificates manually. Run Windows Update and check for optional updates under "Updates for Microsoft products." But don't rely on that alone – Microsoft stopped pushing root updates through Windows Update in 2020. Instead, download the latest root certificate bundle from Microsoft's official root certificate program or grab the rootsupd.exe tool from an old KB (KB931125). Install it and reboot.
Disable HTTPS scanning in your antivirus. This is the second most common cause. Bitdefender, Norton, McAfee, and even Windows Defender's tamper protection can inject their own certificate and break the chain. Go into your AV settings and turn off "SSL scanning" or "HTTPS inspection." If you can't find it, temporarily uninstall the AV and test.
Check the system time. A wrong date or time – even by a few hours – can break certificate validation. Sync with time.windows.com and make sure the time zone is correct.

Why this works

When Windows tries to verify a site's certificate, it builds a chain from the site's cert up to a trusted root authority (like DigiCert or Let's Encrypt). If the root certificate is missing, expired, or flagged as untrusted, that chain fails. Updating the root store replaces those missing certs. Disabling HTTPS scanning removes the middleman – your antivirus – that was intercepting the traffic with its own cert, which your system didn't trust.

Less common variations

Corporate proxy or firewall interception

If you're on a corporate network, your IT team might be using a proxy (like Zscaler or Blue Coat) that re-encrypts traffic with a company-issued certificate. That cert isn't in your personal store. You'll need to get the company's root CA certificate from IT and import it into Trusted Root Certification Authorities via certmgr.msc. Manual approach: open certmgr.msc, go to Trusted Root Certification Authorities > Certificates, right-click, choose All Tasks > Import, and point to the .cer file they give you.

Corrupted certificate store from a bad update

Windows Update or a software installation can corrupt the root store. I've seen this after a failed Windows 10 22H2 update. Fix it by running sfc /scannow followed by dism /online /cleanup-image /restorehealth. Then delete the %SystemRoot%\System32\catroot2 folder (Windows will rebuild it) and reboot.

Self-signed certificates or internal apps

Developers often run into 0x800B010A with self-signed certificates for local development servers (like IIS Express or Node.js). If you trust the app, import its cert manually. Open certmgr.msc, go to Trusted Root Certification Authorities, import the .pfx file, and for production, get a real cert from Let's Encrypt.

Prevention

Keep root certs updated. Run certutil -store root to list them. Use a scheduled task to check for updates monthly. Or use a third-party tool like certupdate from the ca-certificates project.
Don't let AV software intercept all HTTPS. Unless you absolutely need deep packet inspection, disable SSL scanning. It breaks more than it fixes.
If you're in an enterprise, push the company root CA via Group Policy. Set it under Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities.
Monitor system time. Enable NTP sync and set a group policy to enforce it. Time drift is a silent killer of certificate trust.

"Every time I see 0x800B010A, I check the clock first, then the AV. Nine times out of ten, it's one of those two."

That's it. If you used the steps above and still get the error, you're looking at a deeper issue – like a malicious root cert injected by malware. Run a full Windows Defender offline scan or check for suspicious entries in certmgr.msc. But for 99% of cases, updating the root store or killing HTTPS scanning does the job.