CERT_E_UNTRUSTEDCA Fix (0x800B0112) – No Fluff

You've seen it. You're annoyed. Let's fix it.

That 0x800B0112 error — CERT_E_UNTRUSTEDCA — means Windows doesn't trust the certificate authority that issued the cert. Could be a website, an email server, or an internal app. Here's what to do.

The Quick Fix (Works 90% of the Time)

Skip the deep dive. Try this first:

Update the root certificates. Run this in an admin PowerShell:
```
certutil -generateSSTFromWU roots.sst
certutil -addstore Root roots.sst
```
This pulls the latest trusted root list from Microsoft's update server. I had a client last month whose entire internal SharePoint farm broke because an old Windows 10 build was missing a new GlobalSign root. This fixed it in 30 seconds.
Check the date and time. Sounds dumb, but I've seen it half a dozen times. If the system clock is off by hours or years, certificate validation fails. Right-click the clock → Adjust date/time → sync now.
Clear SSL state. Open Internet Options → Content tab → Clear SSL state. This purges bad cached certs. Restart the browser.

Why It Worked

Windows keeps a store of trusted root certificates. If the CA's root isn't there — because it expired, got revoked, or was never added — any cert chaining to it is marked untrusted. The certutil -generateSSTFromWU command downloads the current Microsoft-trusted root list and merges it into your local store. It's the same list that Windows Update uses, but without forcing a full Windows update.

This issue shows up most often with:

Chrome or Edge on older Windows 10 builds (pre-1903)
Outlook connecting to Exchange Online with an expired intermediate
Internal web apps using a cert from a CA that recently changed its root (e.g., Let's Encrypt's ISRG Root X1 expired in 2024)

Less Common Variations & Their Fixes

Self-Signed Certificates

If the cert is self-signed (common for dev servers or internal tools), Windows won't trust it by default. The real fix: export the self-signed cert from the server as a .cer file, then install it to the Trusted Root Certification Authorities store on each client. Double-click the .cer → Install Certificate → Local Machine → Place all certificates in the following store → Browse → Trusted Root Certification Authorities.

Enterprise CA – Group Policy Issue

In a domain environment, if your internal CA's root isn't being pushed via Group Policy, you'll see this error. Check gpresult /h gp.html to see if the Certificate Services client policy is applying. If not, run certlm.msc → Trusted Root Certificates → see if your CA's root is there manually. If it's missing, you can import it from the CA server's \CA_Server\CertEnroll\*.crt file.

Outdated or Corrupted Intermediate Certificates

Sometimes the root is fine, but the intermediate is stale. Open the failing URL in Chrome, click the padlock → Certificate → Certification Path. If you see a red X on an intermediate, download the correct intermediate from the CA's website and install it to the Intermediate Certification Authorities store. I had a client whose payroll app broke because an old Comodo intermediate expired. Took five minutes to fix.

Registry Hack (Last Resort)

If you're dealing with a legacy app that refuses to validate correctly, you can bypass certificate checking entirely — but only on a test machine. This is dangerous. Don't do it on production. Add this registry key:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings" /v "CertificateRevocation" /t REG_DWORD /d 0 /f

This disables revocation checks. It's a band-aid, not a fix. Use it only to diagnose whether the issue is the revocation check itself (rare) or a missing root (common).

Prevention: Stop This From Happening Again

Keep Windows updated. Monthly rollups include root certificate updates. If you defer updates past 6 months, you're asking for this error.
Monitor certificate expiration. Use a tool like certutil -view or third-party cert scanner to flag expiring roots and intermediates. I set calendar reminders 30 days out.
Use a trusted CA for internal certs. If you're still using self-signed for anything beyond dev, move to a proper internal CA (Windows Server AD CS or a third-party like DigiCert). Distribute the root via GPO.
Test certificate chains. Run openssl s_client -connect yourserver:443 -showcerts from a test machine to verify the chain is complete. If you see errors about 'unable to get local issuer certificate', you've found the problem early.

That's it. No fluff. Fix the trust store, check the clock, and move on. You've got better things to do than babysit certificates.