TRUST_E_EXPLICIT_DISTRUST (0x800B0111): Fix Certificate Untrusted Error

What 0x800B0111 actually means

The error string is literal: "The certificate was explicitly marked as untrusted by the user." Windows isn't guessing. Somewhere in the certificate store, that cert sits inside the Disallowed folder. That folder is a deliberate blacklist. Anything in it gets rejected, even if the chain is valid, even if the cert is signed by a trusted root, even if the expiry date is fine.

You get this error when you try to run a signed installer, load a PowerShell module, hit a TLS endpoint in a .NET app, or open a signed macro. Common trigger: an IT admin clicked "Never trust this certificate" during a UAC prompt months ago, then forgot. Or a security tool auto-blacklisted a cert during an incident, and the blacklist entry outlived the incident.

What's actually happening: CryptoAPI walks the chain, checks the Disallowed store, finds a match, and bails with TRUST_E_EXPLICIT_DISTRUST. It never gets to revocation checks or signature validation.

Step 1 — The 30-second fix: remove the cert from the Disallowed store

Open an elevated PowerShell. Not a normal one. The Disallowed store is per-user and per-machine, and the machine copy needs admin.

# See what's blacklisted in your user store
Get-ChildItem Cert:\CurrentUser\Disallowed

# And the machine-wide list
Get-ChildItem Cert:\LocalMachine\Disallowed

Look for a thumbprint that matches the cert in your error. If the error dialog gave you a thumbprint, cross-reference it. If you don't have one, look for a subject name that matches the software or site you're trying to use.

Now delete it. From the user store:

Remove-Item Cert:\CurrentUser\Disallowed\<Thumbprint>

From the machine store (needs admin):

Remove-Item Cert:\LocalMachine\Disallowed\<Thumbprint>

Alternative GUI path: certmgr.msc for the user store, certlm.msc for the machine store. Under Untrusted Certificates > Certificates, right-click the offender and delete it. That's the same operation, just clickier.

Try your original action again. Most people stop here. The reason step 1 works is that the Disallowed store has veto power over everything else in the chain-building logic. Remove the veto, trust evaluates normally again.

Step 2 — The 5-minute fix: if the cert keeps coming back

If you delete the cert, it works briefly, then the error returns, something is putting it back. Three usual suspects:

1. Group Policy. A GPO is pushing the Disallowed store from your domain. Run gpresult /h gpreport.html and open the report. Search for "Disallowed" or the cert's subject. If it's there, the fix is a GPO change, not a local one. Talk to whoever owns the policy. If you're the owner, look under Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies or the equivalent User Configuration branch.
2. Third-party security software. Some endpoint agents (older versions of certain AV suites, some MDM clients) auto-populate Disallowed entries when they flag a publisher. Check the vendor's console for a certificate blacklist feature and remove the entry there. Deleting locally does nothing if the agent re-syncs hourly.
3. A login script or scheduled task. Someone wrote a script that imports a cert into Disallowed on every boot. Search C:\Windows\System32\GroupPolicy\ and your scheduled tasks for Import-Certificate or certutil -addstore Disallowed.

Once you've found the source, kill it at the source. Otherwise you're playing whack-a-mole.

Step 3 — The 15-minute fix: if the cert isn't in Disallowed at all

This one trips people up. The error text says "explicitly marked as untrusted," but you've checked both Disallowed stores and there's nothing there. What's going on?

Three possibilities, in order of likelihood:

The cert is in a different user's store

If the failing process runs as SYSTEM, a service account, or a different logged-in user, it uses that account's Disallowed store. Check the profile that owns the process. For services, that's often LocalSystem. You can enumerate every store on the box:

Get-ChildItem -Path Cert:\ -Recurse -ErrorAction SilentlyContinue |
  Where-Object { $_.PSPath -like '*Disallowed*' }

That walks all stores for all users you have access to. Run it elevated.

It's in the personal Disallowed store of a smart card or token

Hardware-backed certs (YubiKey, smart cards, some TPM-backed certs) can have their own store layout. Open certmgr.msc, look under Personal, and check whether the cert is also listed as untrusted at the token layer. Some middleware has a separate "revoked" list.

The cert isn't the problem — the chain is

Sometimes a parent or intermediate in the chain is blacklisted, not the leaf. Windows reports the error at the leaf because that's what you asked it to validate. Open the cert in certmgr.msc, go to the Certification Path tab, and check each cert in the chain against the Disallowed store. Delete whichever link is blacklisted.

While you're there, look at the General tab. If it says "This certificate has an invalid digital signature" or the chain shows a broken padlock, the Disallowed entry might be hiding a genuinely bad cert. Don't whitelist a cert that's actually compromised — the person who blacklisted it might have had a reason.

Why this error is so confusing

Most certificate errors (expired, revoked, untrusted root) describe a property of the cert. This one describes a decision. That's why the fix is different. You're not repairing the cert. You're reversing a judgment call that was made earlier, probably by a human, probably by accident.

If you inherited this machine from a security-conscious colleague, check the Disallowed store before you do anything else. Half the cases I've seen were a well-meaning lockdown someone forgot to document.

Verifying the fix

Run the original command or open the original app. If it still fails, check the Windows event log at Applications and Services Logs > Microsoft > Windows > CAPI2 > Operational. Enable that log if it's off — it's hidden by default. Then reproduce the error and read the trace. CAPI2 will tell you exactly which cert in the chain failed and why. That's usually faster than guessing.

For a quick sanity check on any cert file:

certutil -verify -urlfetch yourcert.cer

If it comes back clean and the app still fails, you've got a different problem wearing the same error code. Check application-specific trust stores (Java keystore, .NET trust config, browser NSS store) — they don't always share Windows' view of the world.