ErrorHarbor
Error Library

SignTool 0x800B0109: A Certificate Chain Processed, but Terminated in a Root Certificate Which Is Not Trusted

SignTool error 0x800B0109 means the chain Windows evaluated terminated at a root that was not trusted under that verification policy/context. Do not assume that observed chain is the chain you intended, and do not import a root certificate or blindly add /pa first. Identify the artifact, intended policy, observed signer/chain/root, expected chain, and trust context; then fix only the boundary that differs.

SignTool · 0x800B0109 · CERT_E_UNTRUSTEDROOTAuthenticode · Drivers · MSIX · PKILast reviewed Sep 27, 2026
🎯 You’re likely in the right place if:
SignTool verification reports A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider or 0x800B0109.The file can already be signed; the failure is now certificate-chain trust or verification policy.The result changes by machine, user/service account, MSIX install context, or by /pa versus driver-policy verification.
Choose your artifact before changing trust
EXE / MSI / general AuthenticodeVerify with the Default Authentication policy using /pa, then inspect the chain if trust still fails.
Kernel-mode driver / driver catalogDo not use /pa merely to make the error disappear. If kernel-mode policy is what you need to validate, test that policy with /kp; for OS-specific driver/catalog validation, Microsoft also recommends specifying the target OS with /o.
MSIX / App InstallerUse the MSIX trust model. For development certificates, Microsoft specifically documents Local Computer → Trusted People.
Self-signed development certificateBeing present in Personal/My proves availability, not trust. Validate the certificate identity before trusting it anywhere.
Works for one account/machine onlyCompare Current User, Local Machine, service identity, enterprise policy, and chain-building context.
Difficulty: Moderate–AdvancedTrust-store changes: security-sensitive
🔎 Quick Check — verify the artifact with the policy you actually intend

General Authenticode EXE/MSI:

signtool verify /pa /v "app.exe"

Kernel-mode driver policy:

signtool verify /kp /v "driver.sys"
Security gate: do not download or import an unknown root certificate just to remove 0x800B0109. A trusted root can authorize certificate chains on that machine. Confirm the certificate/root identity and your organization or issuer’s documented trust path first.
ADSENSE · reserved slot after the first useful step

30-second decision — which branch should you use?

A
Normal Windows app (.exe/.msi)?
Start with signtool verify /pa /v. If 0x800B0109 remains, inspect the chain and trust context below.
B
Kernel driver (.sys) or driver catalog (.cat)?
If kernel-mode policy is what must pass, use /kp. Do not switch to /pa merely to get a successful result.
C
Installing an MSIX with a development certificate?
Skip generic root-store advice and go to the MSIX branch. Microsoft documents Local Computer → Trusted People for this development scenario.
D
Not sure what the certificate stores mean?
Personal/My = certificates available to that identity; Trusted Root = trust anchors; Intermediate = CA certificates between signer and root; Trusted People = explicitly trusted end certificates used by specific Windows scenarios. These stores are not interchangeable.

Diagnostic flow — artifact → policy → chain → trust context

1
Identify the artifact and intended verification policy.
EXE/MSI, kernel driver/catalog, and MSIX do not share one universal “trust-store fix.”
2
Compare the observed chain with the expected chain.
0x800B0109 identifies an untrusted root in the evaluated path, but that path may not be the issuer/root path you expected. Record signer → intermediates → root before changing trust.
3
Identify the trust context.
Current User, Local Machine, App Installer, service account, CI runner, or enterprise/GPO-managed root store.
4
Change trust only after validating the certificate/root.
Prefer issuer/organization deployment guidance over ad-hoc manual root imports.

Fix #1 — do not confuse /pa with a universal trust repair

Microsoft documents /pa as the Default Authentication Verification Policy. Without it, SignTool verification can use the Windows Driver Verification Policy. That means adding /pa can be the correct test for a normal Authenticode executable—but it can also hide the fact that you were intentionally testing a driver under a different policy.

Decision: if the artifact is a normal EXE/MSI, test /pa. If you must validate kernel-mode signing requirements, keep the appropriate driver policy such as /kp and fix that trust/policy failure instead.

Verify: rerun with the intended policy. If 0x800B0109 remains, move to the certificate chain and trust context; do not keep switching flags until one passes.

Fix #2 — inspect the signing certificate and chain before trusting anything

Open the signed file’s Digital Signatures details or use approved certificate tooling to inspect the signer, issuer chain, validity, and root that Windows actually evaluated. Compare that observed chain with the issuer/root path expected from your CA, enterprise PKI or development PKI. If Windows selected or constructed an unexpected path, trusting its terminal root blindly can hide the real chain-distribution/policy problem.

Do not collapse two different errors: CERT_E_UNTRUSTEDROOT (0x800B0109) means Windows processed a chain to a root that is not trusted. CERT_E_CHAINING (0x800B010A) means a chain to a trusted root could not be built. If your actual code is 0x800B010A, missing intermediate/chain discovery becomes the primary branch; do not treat this 0x800B0109 guide as an exact match.

Verify: identify the expected root and intermediate(s), and confirm their fingerprints/issuers through your CA, organization, or development PKI documentation before any store change.

Fix #3 — self-signed/dev certificate: Personal is not Trusted Root

A self-signed certificate can exist in CurrentUser\My or another Personal store and still fail verification. The Personal/My store makes a certificate available to an identity; it does not automatically establish that certificate as a trusted root.

Development only: if your workflow intentionally uses a self-signed development root, trust it only on the machines/scopes that require that development trust and only after verifying its fingerprint. Do not turn a development workaround into broad production trust.

Verify: rerun the intended SignTool policy after the approved development trust is deployed. The chain should terminate at the expected trusted development root—not merely “some certificate that makes verification pass.”

Fix #4 — MSIX/App Installer has its own trust branch

For the Microsoft-documented MSIX development-certificate scenario that produces 0x800B0109, the documented trust step uses Local Computer → Trusted People. Keep this scoped to that development/install model and a certificate whose identity you have validated; enterprise/public production signing should follow its own deployment and trust model.

Do not generalize this to every SignTool error. Trusted People for an MSIX development certificate is a documented MSIX branch; it is not a universal replacement for Trusted Root, enterprise PKI deployment, or driver-signing policy.

Verify: after following the applicable Microsoft MSIX development trust procedure for the validated certificate, retry the same package/install path on the same machine context that originally produced 0x800B0109. Do not treat a separate SignTool /pa pass as proof that App Installer's original trust path is fixed.

Fix #5 — Current User vs Local Machine vs service/CI identity

If verification works interactively but fails in a service, installer, build runner, or another account, compare the trust context instead of reissuing the certificate. A service account can have a different user store; an installer can require machine-level trust; enterprise policy can also control which roots are accepted.

whoami Get-ChildItem Cert:\CurrentUser\Root | Select-Object Subject, Thumbprint Get-ChildItem Cert:\LocalMachine\Root | Select-Object Subject, Thumbprint

Verify: compare only the expected CA/root across the relevant scopes. Do not “synchronize” stores by bulk-importing certificates.

Fix #6 — only branch to intermediates when chain building points there

When the signer should chain to a trusted public or enterprise root but Windows cannot build that expected path, inspect the intermediate CA certificates and chain-discovery path. Intermediate certificates normally belong in the Intermediate Certification Authorities store—not Trusted Root.

Important distinction: installing an intermediate as a trusted root changes the security meaning of the chain. Fix the chain placement/distribution instead of promoting an intermediate to root trust.

Verify: after the approved intermediate is available, rebuild/verify the chain and confirm it reaches the expected trusted root under the intended policy.

Fix #7 — enterprise/GPO case: use CAPI2 before changing managed trust

If a known organizational/public root appears valid but Windows still reports it untrusted—especially on domain-managed machines—inspect the CAPI2 Operational log. Microsoft specifically recommends CAPI2 for diagnosing root-store and chain-policy problems, including Group Policy-managed trust.

Useful events: CAPI2 Event 11 records chain building; Event 30 records chain-policy verification. Use them to see which certificates and policy Windows actually evaluated.

Verify: reproduce the failure, correlate the CAPI2 events, and resolve the documented enterprise trust/GPO issue. Do not fight centrally managed trust by manually adding roots to individual machines.

Driver/catalog edge case — verify against the intended Windows version

For driver and system-catalog verification, Microsoft recommends the /o option to specify the operating-system version being targeted. Without it, a catalog that validates for one Windows version can produce an unexpected result when evaluated against another.

Do not guess an /o value. Use the PlatformID and Windows version that match the driver package you actually support, following Microsoft’s SignTool syntax and driver-signing documentation.

Verify: rerun the driver/catalog verification using the intended kernel policy and target OS. Keep 0x800B0109 diagnosis focused on the chain/root Windows evaluates under that real target context.

Final verification — prove the intended policy passes

Repeat verification using the same policy that matters for your artifact. A passing /pa test does not prove kernel-mode policy passes, and a certificate visible in a store does not prove the relevant identity trusts its chain.

signtool verify /pa /v "app.exe" signtool verify /kp /v "driver.sys"

Verify: reproduce the original validation path using the policy/context that actually matters. Confirm the expected signer, observed chain, expected root, timestamp/countersignature where relevant, and verification result rather than treating a different policy or exit code alone as evidence.

What not to do

Do not import a root certificate from an unknown download/forum just to suppress 0x800B0109.Do not add /pa to a kernel-driver check merely because it produces a green result.Do not assume CurrentUser\My or LocalMachine\My means the certificate is trusted.Do not place an intermediate CA into Trusted Root as a shortcut.Do not bulk-copy Current User roots into Local Machine.Do not manually override enterprise/GPO trust before identifying why managed chain policy failed.Do not assume the root shown in the failing chain is the root you intended; compare the observed chain with the expected issuer path before trusting anything.Do not generalize the MSIX development Trusted People procedure to unrelated production Authenticode, enterprise PKI, or driver-signing trust.Do not use a passing /pa verification as proof that the original /kp, App Installer, service, or other policy/context is fixed.Do not keep diagnosing 0x800B0109 if the original path progresses and returns a different chain, revocation, timestamp, policy or signature error.

Still seeing 0x800B0109?

Capture these before escalating:artifact type: EXE/MSI, driver/catalog, or MSIXexact SignTool verify command and whether /pa or /kp is intendedsigner subject/thumbprint and expected issuer/rootwhether the certificate is public CA, enterprise CA, or intentionally self-signed/devCurrent User vs Local Machine vs service/CI identitychain view showing where trust terminatesrelevant CAPI2 Event 11/30 details for managed/ambiguous casesthe observed signer → intermediate(s) → root chain versus the chain your issuer/PKI documentation says should be usedwhether the failing verification also evaluates a timestamp/countersignature and which chain actually carries 0x800B0109the exact original validation path: /pa, /kp, App Installer/MSIX, service/CI, or another consumerthe first different error after the intended trust path succeeds

If SignTool cannot find a signing certificate at all, use No Certificates Were Found That Met All the Given Criteria. If signing succeeds but timestamping fails, use Timestamp Server Could Not Be Reached or Returned an Invalid Response.

Official references

Microsoft: SignToolOfficial verification policies including /pa and /kp →Microsoft: SignTool for driver packagesKernel-mode and catalog verification examples →Microsoft: MSIX troubleshooting0x800B0109 and development certificate trust guidance →Microsoft: valid root certificates appear untrustedEnterprise/GPO trust and CAPI2 diagnosis →

Still stuck? Ask the community

Share the artifact type, intended /pa or /kp policy, signer/root identity with sensitive details redacted, trust scope, and the exact 0x800B0109 output.

Keep it safe: never post PFX files, private keys, passwords, tokens, internal PKI secrets, private URLs, or confidential build logs.
Powered by GitHub DiscussionsSign in with GitHub to comment. Reading comments does not require sign-in.

Loading community discussion…