0x800b0109 Certificate Chain Problems: Restoring Trust Stores

If you’ve just hit error 0x800b0109, you’re seeing a trust problem: Windows can’t validate a certificate chain because it ends at a root certificate your system doesn’t trust. This tends to appear during Windows Update, when installing drivers or apps, or when your network security tools intercept TLS traffic. Because it blocks updates and installations, it’s critical to fix quickly. This guide goes beyond generic advice with precise, step-by-step troubleshooting to restore your Windows trust stores and get updates installing again.

Understanding the Error
— What 0x800b0109 means in plain language

The code 0x800b0109 maps to CERT_E_UNTRUSTEDROOT: “A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.” In plain terms, Windows tried to verify the digital signature on an update, driver, or installer. Verification requires building a certificate chain from the file’s signing certificate up through intermediate certificates to a trusted root. If the chain ends at a root your system doesn’t trust (or can’t reach to validate), verification fails and you get 0x800b0109.

Common scenarios that trigger it:

• Windows Update cannot verify the Microsoft signature on .cab/.msu files.
• An installer (.msi/.exe) or driver is signed, but your PC lacks required intermediate or root certificates.
• Your time/date are wrong, causing certificate expiration/validity checks to fail.
• Cryptographic Services or Windows Update components are corrupted or stopped (SoftwareDistribution/catroot2 issues).
• Your organization’s proxy or antivirus performs SSL inspection, replacing Microsoft certificates with a non-Microsoft root not trusted by Windows Update verification.
• Group Policy disables automatic root certificate updates, leaving your root store stale.
• Offline or isolated machines cannot download the latest roots or revocation lists (CRL/OCSP).
• Legacy OS or TLS settings prevent retrieving certificate or revocation data.

Quick Reference Table

Cause	Symptom	Recommended Fix
Wrong date/time or time zone	Update/installer fails immediately with 0x800b0109	Correct system and BIOS clock, sync with NTP, retry
Cryptographic Services stopped or corrupted catroot2	Windows Update fails; Event Viewer shows CAPI2 errors	Restart services; reset SoftwareDistribution and catroot2 folders
Stale/missing trusted roots	Windows Update or signed installers fail on fresh/isolated systems	Refresh trust stores via certutil from Windows Update or a healthy machine
Missing intermediate certificates	Signature appears “Invalid” even though root exists	Use certutil/signtool to fetch and install required intermediates
SSL inspection or proxy rewriting certs	Updates fail behind corporate network; chain shows non-MS root	Exclude Microsoft/CRL/OCSP endpoints from TLS inspection; reset WinHTTP proxy
Group Policy blocks automatic root updates	Event ID 4107/13 in CAPI2; inability to obtain authroot updates	Disable “Turn off Automatic Root Certificates Update”
Corrupted Windows Update components	Frequent signature verification failures	Reset WU components and caches, run SFC/DISM
Legacy TLS settings (old OS)	CRL/OCSP or root download fails	Enable TLS 1.2 for WinHTTP/SChannel (legacy systems)

Common Causes

• Incorrect system time or time zone
• Disabled or malfunctioning Cryptographic Services
• Corrupted Windows Update caches (SoftwareDistribution/catroot2)
• Stale or missing Trusted Root Certification Authorities
• Missing intermediate CA certificates
• SSL inspection/firewalls/proxies altering server certificates
• Group Policy disabling automatic root certificate updates
• No Internet access to Microsoft root/CRL/OCSP endpoints (isolated networks)
• Corruption in servicing stack or signature catalogs
• Third-party security software interfering with trust validation
• Legacy OS missing SHA-2 or TLS 1.2 updates (older Windows editions)

Preliminary Checks

• Boot into Safe Mode (if needed)

  • If regular boot is unstable, boot to Safe Mode:
    • Windows 10/11: Settings > Update & Security > Recovery > Advanced startup > Restart now. Then Troubleshoot > Advanced options > Startup Settings > Restart > choose Enable Safe Mode with Networking.
  • Note: Most certificate fixes work in normal mode; Safe Mode is a fallback.

• Back up important data

  • Before deep repairs, back up key files or take a system restore point:
    • Control Panel > System > System Protection > Create.

• Run basic health checks

  • Open an elevated Command Prompt (Run as administrator) and run:
    • System File Checker (SFC):
      sfc /scannow
    • DISM Servicing Stack repairs:
      DISM /Online /Cleanup-Image /CheckHealth
      DISM /Online /Cleanup-Image /ScanHealth
      DISM /Online /Cleanup-Image /RestoreHealth
    • Optional disk check (may require reboot):
      chkdsk C: /scan

Step-by-Step Troubleshooting

1. Fix date, time, and NTP sync

• Set the correct time zone and time.
• Sync with an NTP server:
  w32tm /query /status
  w32tm /resync
• Check BIOS/UEFI clock if it keeps drifting.

2. Check network/proxy and disable SSL inspection for Microsoft endpoints

• If behind a corporate proxy or security gateway, temporarily bypass it or whitelist Microsoft update and PKI endpoints. SSL inspection must be disabled for:
  • .windowsupdate.com, .update.microsoft.com, download.windowsupdate.com, ctldl.windowsupdate.com
  • crl.microsoft.com, ocsp.msocsp.com, www.microsoft.com/pki, mscrl.microsoft.com
• Reset WinHTTP proxy on the device:
  netsh winhttp show proxy
  netsh winhttp reset proxy
• If using a proxy, ensure it passes through certificate chains and revocation checks unaltered.

3. Verify required services are running

• Ensure these services are set to Automatic and running:
  • Cryptographic Services (CryptSvc)
  • Windows Update (wuauserv)
  • Background Intelligent Transfer Service (BITS)
• Commands:
  sc query cryptsvc
  sc query wuauserv
  sc query bits
  sc config cryptsvc start= auto
  sc config wuauserv start= demand
  sc config bits start= delayed-auto
  net start cryptsvc
  net start bits
  net start wuauserv

4. Reset Windows Update and catroot2

• Stop services:
  net stop wuauserv
  net stop bits
  net stop cryptsvc
• Rename caches:
  ren %windir%\SoftwareDistribution SoftwareDistribution.old
  ren %windir%\System32\catroot2 catroot2.old
• Restart services:
  net start cryptsvc
  net start bits
  net start wuauserv
• Try the update/installer again.

5. Refresh Trusted Roots and Intermediates from Windows Update
   Option A – Online (recommended):

• Generate updated roots from Windows Update:
  certutil -generateSSTFromWU %TEMP%\roots.sst
• Import them to the Local Machine Trusted Root store:
  certutil -addstore -f root %TEMP%\roots.sst
• Optionally, sync directly (works on many builds):
  certutil -syncWithWU

Option B – Offline (for isolated machines):

• On a healthy, Internet-connected Windows 10/11 machine:
  certutil -generateSSTFromWU %TEMP%\roots.sst
• Copy roots.sst to the offline machine and import:
  certutil -addstore -f root C:\Path\To\roots.sst
• If intermediates are still missing, try to manually import intermediate certificates provided by the software vendor, or allow temporary Internet to fetch AIA/CRL.

6. Verify the signature of the failing file and fetch missing intermediates

• Identify the exact file failing (update .msu/.cab, driver .cat/.inf, installer .msi/.exe).
• Use built-in tools to diagnose:
  • certutil (fetch online chain data):
    certutil -verify -urlfetch C:\Path\To\File.msu
  • signtool (comes with Windows SDK):
    signtool verify /pa /v C:\Path\To\File.msu
• If the chain reports “Cannot build chain” or “Untrusted root,” check whether the root is missing or an intermediate is missing. Install the missing intermediate if provided by the vendor or let Windows fetch it by ensuring Internet access and no SSL inspection.

7. Clear certificate and CTL caches

• Clear URL cache (CRL/OCSP/CTL):
  certutil -urlcache * delete
• Reboot and retry the operation.

8. Repair system files and servicing stack again

• Re-run the baseline repairs after the above steps:
  sfc /scannow
  DISM /Online /Cleanup-Image /RestoreHealth

9. Check Group Policy that may block root updates

• Open gpedit.msc:
  • Computer Configuration > Administrative Templates > System > Internet Communication Management > Internet Communication settings
  • Ensure “Turn off Automatic Root Certificates Update” is Disabled or Not Configured.
• Registry check (if no gpedit):
  • HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot\DisableRootAutoUpdate
  • If present and set to 1, set to 0 or delete the value (then reboot).

10. Review TLS/legacy OS prerequisites (if applicable)

• On older Windows versions, ensure SHA-2 and TLS 1.2 support are present and enabled for WinHTTP/SChannel, otherwise CRL/OCSP and roots download can fail. (Modern Windows 10/11 already have this.)
• Confirm network devices allow outbound TLS 1.2 to Microsoft services.

11. Temporarily disable third-party security software

• Some antivirus/firewall suites inspect HTTPS or inject their own root certificates. Temporarily disable HTTPS scanning or uninstall the product (as a test), reboot, and retry.
• If disabling fixes the issue, create exclusions for the Microsoft and PKI endpoints listed above.

12. For WSUS-managed devices

• Verify the WSUS server uses a valid certificate chain trusted by clients (if using SSL).
• Ensure clients can reach Microsoft CRL/OCSP endpoints; don’t force CRL download through a proxy that inspects TLS.
• Consider temporarily pointing a test client to Microsoft Update (unassign WSUS) to isolate whether WSUS is the cause.

Minidumps vs. logs for 0x800b0109

• 0x800b0109 is not a BSOD, so minidump analysis doesn’t apply. Instead, collect:
  • Windows Update logs:
    • On Windows 10/11:
      PowerShell (Admin): Get-WindowsUpdateLog
      Review the generated desktop log for signature or trust errors.
  • CBS and DISM logs:
    • C:\Windows\Logs\CBS\CBS.log
    • C:\Windows\Logs\DISM\dism.log
  • CAPI2 Operational logs (see Advanced Diagnostics) for certificate chain failures.

Advanced Diagnostics

Use Event Viewer (CAPI2) to pinpoint chain failures

• Open Event Viewer > Applications and Services Logs > Microsoft > Windows > CAPI2 > Operational.
• Look for:
  • Event ID 11, 13: Chain building failures; details show which cert couldn’t be chained.
  • Event ID 4107/4108: “Failed to retrieve the Third-Party Root Certification List from Windows Update” — indicates blocked root updates.
• Double-click events and inspect the XML to see the subject/issuer, AIA/CRL URLs, and exact error (e.g., “revocation offline,” “untrusted root”). This often tells you whether missing intermediates, unreachable CRL/OCSP, or wrong root is to blame.

Deep chain verification with certutil

• To verify a single certificate file and fetch AIA/CRL:
  certutil -verify -urlfetch C:\Path\To\Signer.cer
• To verify the catalog or signature in a package:
  certutil -verify -urlfetch C:\Path\To\File.msu
• If verification fails due to revocation or AIA retrieval, test network access to endpoints shown in the log (use Test-NetConnection or your browser).

Check Store contents and untrusted roots

• List Trusted Roots (Local Machine):
  certutil -store -v root
• List Intermediates:
  certutil -store -v CA
• List Untrusted Certificates:
  certutil -store -v Disallowed
• Remove obviously malicious or expired third-party roots/intermediates with MMC:
  • Start > mmc.exe > File > Add/Remove Snap-in > Certificates > Computer account.
  • Review Trusted Root and Intermediate stores for anomalies.
  • Caution: Do not remove Microsoft roots. When unsure, export before deleting.

Sysinternals Sigcheck helpers (optional)

• Sigcheck (from Microsoft Sysinternals) can check trust and root updates:
  • Verify file and show chain:
    sigcheck -i -v C:\Path\To\File.exe
  • Check if Automatic Root Certificate Update is enabled:
    sigcheck -tv

Driver Verifier note

• Driver Verifier is a BSOD diagnostic tool and does not help with 0x800b0109. If a driver install fails with 0x800b0109, treat it as a signature trust problem (chain/root/intermediate), not a runtime driver bug.

Post-Fix Checklist

• Retry Windows Update or the original installer/driver. It should complete without 0x800b0109.
• Event Viewer: CAPI2 Operational log should be free of new chain build failures and 4107/4108 errors.
• Validate with certutil:
  • Verify the same file that failed earlier:
    certutil -verify -urlfetch C:\Path\To\File.msu
• Run SFC/DISM once more to ensure servicing integrity:
  sfc /scannow
  DISM /Online /Cleanup-Image /RestoreHealth
• Confirm services are in their default startup state and there’s no proxy intercepting Microsoft endpoints.

When to Seek Professional Help

• You’re in an enterprise environment with TLS inspection, custom PKI, or Group Policies you cannot change.
• WSUS/SCCM infrastructure uses custom SSL and clients don’t trust it.
• Persistent 4107/4108 CAPI2 errors despite resets and network whitelist suggest a network/security appliance issue.
• The machine is air-gapped and needs a curated, offline root/intermediate distribution process.
• You suspect malware tampered with trust stores.
• An in-place upgrade repair fails to restore trust behavior.

Prevention Tips

• Keep time synchronized via domain or reliable NTP; monitor for clock drift.
• Allow outbound access (and no SSL interception) to Microsoft Update and PKI endpoints and to CRL/OCSP URLs.
• Do not disable Automatic Root Certificates Update through Group Policy unless you have a managed replacement process.
• Avoid installing unknown third-party root certificates. Audit Trusted Root and Intermediate stores periodically.
• Maintain regular Windows Updates, servicing stack updates (SSUs), and feature releases.
• For enterprises: Document exceptions in security appliances for Microsoft and PKI endpoints; test updates on pilot rings before broad deployment.
• Keep reliable backups or system images to recover quickly from store corruption.

Conclusion

Error 0x800b0109 is a certificate trust problem, not a driver crash or OS meltdown. In most cases, fixing time sync, resetting cryptographic/Windows Update components, refreshing trusted roots, and ensuring network paths to Microsoft and PKI endpoints will resolve it. With the steps above, you can methodically restore your trust stores and get Windows Update and signed installers running again.

FAQ

What does 0x800b0109 mean exactly?

It maps to CERT_E_UNTRUSTEDROOT: Windows built a certificate chain for a signed file but the chain ended at a root certificate that isn’t trusted by your system. This usually indicates missing or outdated trusted roots, a blocked revocation/chain fetch, or TLS interception altering certificates.

How do I restore the default trusted root certificates?

Use certutil to refresh roots from Windows Update:

• Online:
  certutil -generateSSTFromWU %TEMP%\roots.sst
  certutil -addstore -f root %TEMP%\roots.sst
• Offline: Generate roots.sst on a healthy machine, copy it, and import with certutil -addstore -f root. Ensure Group Policy isn’t disabling Automatic Root Certificates Update.

Is it safe to delete the catroot2 folder?

You don’t delete it; you rename it while services are stopped so Windows can rebuild it. This is a standard, safe repair step when signature verification or Windows Update is failing:

• Stop wuauserv, bits, cryptsvc
• Rename %windir%\System32\catroot2 to catroot2.old
• Restart services and reboot

How can I tell if my proxy or firewall is causing 0x800b0109?

If updates work off-network or on a different connection, or if Event Viewer CAPI2 logs show failures to reach CRL/OCSP or Windows Update endpoints, the proxy may be intercepting TLS or blocking PKI traffic. Disable SSL inspection for Microsoft/PKI endpoints or temporarily bypass the proxy to confirm.

What logs should I check since there’s no minidump?

• Windows Update: Get-WindowsUpdateLog (on Windows 10/11)
• CBS: C:\Windows\Logs\CBS\CBS.log
• DISM: C:\Windows\Logs\DISM\dism.log
• CAPI2 Operational log: Event Viewer > Applications and Services Logs > Microsoft > Windows > CAPI2 > Operational

Stay patient and systematic—most 0x800b0109 trust issues are fixable with the steps above. If you’re in a managed environment, partner with your IT/security team to adjust policies and SSL inspection settings appropriately. You’ve got this.