Windows System Errors
Untrusted Root Certificate
0x800B0109Reviewed for reference consistency: August 11, 2026
the certificate chain ends at a root the trust provider rejects
What 0x800B0109 Means
The 0x800B0109 error on the Windows System Errors indicates untrusted root certificate — the certificate chain ends at a root the trust provider rejects. This typically occurs due to the signing certificate's root ca is not present in the machine's trusted root store.
Certificate chains can verify cleanly and still be refused at the last step: 0x800B0109, CERT_E_UNTRUSTEDROOT, fires when the chain terminates in a root certificate the trust provider does not trust. Microsoft's DirectAccess troubleshooting documents the code for IP-HTTPS connections, and the same failure governs update packages — a file whose signature chains to an untrusted root fails validation rather than installation.
How to fix 0x800B0109
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
List the machine's trusted root certificates
The trusted-root listing shows which roots the local store actually holds, against which the signing chain's root can be compared.
certutil -store rootRead the CAPI2 channel for validation detail
The CAPI2 operational log records chain-building events with the failing element, which names the exact certificate that could not be trusted.
wevtutil qe Microsoft-Windows-CAPI2/Operational /q:"*[System[(Level=2)]]" /c:25 /rd:true /f:text
Technical Background
Chain validation is transitive trust: the leaf is checked, then the issuer, then onward to a root. The engine does not judge the root's quality — only whether the local trust store contains it and the chain's constraints hold. A missing root therefore produces the same refusal as a wrong one, and the remedy in both stories is the propagation of the correct root certificate rather than any change to the signed file.
Update pipelines make the failure visible because signing is mandatory. Packages published through WSUS carry a publisher's certificate; if that certificate's root was never distributed, every client refuses the package with CERT_E_UNTRUSTEDROOT no matter how valid the package content is. The DirectAccess article documents the mirror-image case for IP-HTTPS, where the client refuses the server's certificate for the same reason.
Common Causes
- The signing certificate's root CA is not present in the machine's trusted root store
- A WSUS-deployed third-party signing certificate was never distributed to clients
- Enterprise root CA certificates failed to propagate through Group Policy
Typical Scenarios
- Third-party updates published through WSUS fail to install because the vendor's signing certificate is not in clients' trusted root store
- A DirectAccess client's IP-HTTPS interface rejects the server certificate with 0x800B0109
- A newly deployed internal CA's root has not yet reached the client, so every chain through it is refused
What to Know
The trust store, not the network, is the scene here: comparing the signing chain's root against the local trusted-root store distinguishes a propagation gap from a genuinely wrong certificate.
Frequently Asked Questions
Common questions about Windows 0x800B0109 error
That the certificate chain terminates in a root the local trust provider trusts. The chain itself can be well formed — the refusal is the absence of that root from the machine's trusted store.
Those packages are signed with the publisher's certificate. If its root CA was never distributed to clients, signature validation fails with 0x800B0109 on every machine the package reaches.
0x8007000D reports data that cannot be parsed at all. 0x800B0109 reports content that parsed, validated structurally, and then failed the trust decision at the root.
Related Error Codes
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
Git's internal object database is missing or corrupted.
The operating system denied Git's request for more RAM during a heavy operation.
Git detected corruption inside one of its compressed data bundles (packfiles).
An uncompressed file in Git's internal database has an invalid checksum or zero bytes.