Error 0x80092012: TLS inspection breaks certificate checks on the client

Fix it now

0x80092012 is CRYPT_E_NO_REVOCATION_CHECK: the revocation function was unable to check revocation for the certificate. It is not saying the certificate is bad, only that it could not find out. The usual reason on a managed network is HTTPS inspection – a product reissues certificates under its own authority, and either that chain is not trusted or the lookups it needs are blocked.

certutil -verify -urlfetch C:\temp\server.cer
certutil -urlcache * delete
netsh winhttp show proxy
w32tm /query /status

1. Read the certutil output. It names every revocation URL it tried and what happened to each, which is the whole diagnosis in one screen.
2. If the issuer is your security product or gateway rather than a public authority, HTTPS inspection is in the path and the rest of the work is about trusting it properly.
3. Confirm the inspection authority is trusted machine-wide, not just for the signed-in user: open certlm.msc and look under Trusted Root Certification Authorities. Services and scheduled tasks read that store, not the user’s.
4. If the revocation URLs time out, allow them through the proxy and exempt them from inspection. They are plain HTTP by design, and blocking outbound port 80 is the most common single cause of this error.

certutil -urlcache * delete clears the current user’s cache. A service failing under the machine account is looking at a different cache, so clear it in that context or restart the service after the underlying fix.

If certutil now returns a revocation result for every link in the chain, you are done. If not, the next section explains what the chain engine is trying to do and which of the four companion codes you really have.

Why it happens

When Windows validates a certificate it builds a chain to a trusted root and then checks each link for revocation. It learns where to check from fields inside the certificate: the CRL distribution point gives a URL for a revocation list, and the authority information access field gives an OCSP responder address. Both are ordinary HTTP fetches. If they fail, the engine has a chain it can build but cannot vouch for, and it returns 0x80092012.

HTTPS inspection breaks this in three ways at once. It replaces the real certificate with one it issues on the fly, so the original revocation pointers are gone. It usually publishes nothing in their place, because a locally issued certificate has no public revocation list. And the device performing the inspection frequently blocks plain outbound HTTP, which is exactly the protocol CRL and OCSP use.

The result moves around in a way that looks arbitrary until you know why. A browser succeeds while an application fails, because they use different trust stores and different revocation policies. A machine-context process fails while the interactive user succeeds, because the inspection authority was installed into that user’s store rather than the computer’s. The companion codes tell you which of these you have: 0x800B0101 is CERT_E_EXPIRED, which Microsoft states as the certificate having either expired or not yet become valid; 0x800B010F is CERT_E_CN_NO_MATCH, the common name of the certificate not matching the value the application specified; and 0x80092010 is CRYPT_E_REVOKED, which is the one case where the answer came back and the answer was yes.

Full reference

The four codes, as Microsoft states them

The last row is the one to take seriously. 0x80092010 is not a plumbing failure: the lookup succeeded and the issuer has withdrawn the certificate. Nothing in this article applies to it. Find out why it was revoked before you do anything else, and treat a revoked certificate on an internal service as an incident until you know otherwise.

Reading certutil output properly

1. certutil -verify -urlfetch <file.cer> builds the chain and, because of -urlfetch, actually retrieves the AIA certificates and CDP revocation lists rather than relying on what is cached.
2. Work down the output looking for each URL and the result beside it. A URL that returns a list is fine; one that times out is your blocked lookup.
3. Run it as the account that fails. An administrator session and a service running as the machine account do not share a proxy configuration or a URL cache.
4. Clear stale results with certutil -urlcache * delete, which Microsoft documents as deleting the relevant URLs from the current user’s local cache, and repeat.

Commands worth knowing

Microsoft’s own note on certutil is worth repeating: it is not recommended for use in production code and carries no guarantee of application compatibility. As an interactive diagnostic it is excellent; as a component of a script that other people depend on, it is a liability.

Why the browser works when your application does not

Browsers generally soft-fail revocation, treating an unreachable responder as acceptable and continuing, while the Windows chain engine and code-signing checks hard-fail and stop. Several browsers and runtimes also carry their own trust stores and their own revocation caches. So a browser succeeding proves almost nothing about the machine’s chain configuration, and testing with one is the most common way people convince themselves a problem is fixed when it is not. Test with certutil -verify -urlfetch, in the account that fails.

Turning revocation checking off

Relaxing revocation behaviour through the chain engine’s configuration under HKLM\SOFTWARE\Microsoft\Cryptography affects every certificate decision the machine makes, including code signing. Export the branch before you touch it, treat the change as a temporary diagnostic, and reverse it. It disables the mechanism that would tell you a stolen certificate has been withdrawn.

Doing inspection properly, if you are going to do it

• Deploy the inspection authority to the computer store on every machine, not the user store, and push it by policy rather than by hand.
• Add it to the trust stores of every runtime that keeps its own – Java, Node.js, Python, Firefox, database drivers.
• Exempt certificate-pinned destinations and software update endpoints by name, and keep that list somewhere people can find it.
• Leave outbound HTTP to revocation endpoints open, and exempt those hosts from inspection so their responses are not rewritten.
• Keep the inspection authority’s own expiry in the calendar. When it lapses, every chain on every machine fails at once.

Every code this article covers

Confirm the fix worked

1. certutil -verify -urlfetch against the certificate that failed returns a result for every revocation check rather than a timeout.
2. The inspection authority appears under Trusted Root Certification Authorities in certlm.msc, the computer store.
3. The failing operation succeeds from a service or scheduled task context, not only as the signed-in user.
4. w32tm /query /status shows a small offset from a time source the machine should be using.
5. A second machine built the same way behaves the same, which tells you the fix is in policy rather than on one desktop.

Questions people ask about this