0x80092012 - The revocation function was unable to check revocation for the certificate

[ghost]

Problem My corporate networking software replaces certificates for all 443 connections with its own, corporate-signed cert. I don't expect Cargo to work under these circumstances as it's basically a MITM attack, but I'd like to ask for Cargo to give a better error message if that's possible. Currently, it says:

    Updating crates.io index
warning: spurious network error (2 tries remaining): [28] Timeout was reached (failed to download any data for `cargo-cache v0.5.1` within 30s)
warning: spurious network error (1 tries remaining): [35] SSL connect error (schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.)
error: failed to download from `https://crates.io/api/v1/crates/cargo-cache/0.5.1/download`

I know the cert is substituted and cannot be verified, which makes me think Cargo should've reported a failure to verify such-and-such certificate, maybe print its basic attributes like O, CN etc. Instead it says there is an unknown error and something in a function. Does that make sense please?

Steps

1. Connect to my company's VPN network
2. Clear the Cargo cache
3. Try to install/build anything with Cargo

Possible Solution(s) Clearly state that the problem is that the cert cannot be verified due to such and such, print cert's headers?

Notes

Output of cargo version:

cargo 1.46.0 (149022bld 2020-07-17)

Windows 10 Pro, a corporate image with lots of spyware, AV, etc.

[alexcrichton]

Windows is different from other systems where it checks revocation by default, but as you can see this sometimes fails. You can configure Cargo to not check for revocation, however, by setting:

# in .cargo/config.toml
[http]
check-revoke = false

or setting the CARGO_HTTP_CHECK_REVOKE env var to false

[ghost]

Thanks @alexcrichton. To clarify, Cargo delegates that check to Windows, and the Windows part of it can fail, so the only option is not to perform the check at all. Without the check, there is a security risk. So my only option would be to go for the risk. Did I get it right?

[ghost]

I don't know if it makes any difference, but as soon as I disable the MITM software (Symantec WSS) or disconnect from the corporate VPN, the revocation error disappears. Presumably, the revocation check still works for the proper certificate. So the check itself works... but depends on the certificate it's asked to check.

[alexcrichton]

Yes this check is being delegated to Windows, and that's where the error is coming from. IIRC Windows can be configured to not do this by default, but I don't remember how off the top of my head. I'm not really the one to comment on the security one way or another, but what I can say is that other platforms (Linux and macOS) don't do revocation checks by default.

[ghost]

Is there any way to improve the error message? For one, it says unknown error which is already concerning, and then on top of that the revocation check could not be performed. Not that the check determined the cert is fine or not, but basically that the check itself is broken in some way. That very well could be hidden behind the Windows API Cargo is using, but just on a chance that better info could be extracted?

[alexcrichton]

We'd have to track down ehre the "unknown error" is coming from to see if we can easily improve it. It's generally always possible to improve it one way or another though! If it's from Cargo or the curl crate we can probably pretty easily fix it, but if it's from curl itself it may be harder.

Most of the certificate interactions, though, happen very deeply within native libraries, an area that Cargo only has so much control over.

[Diggsey]

I have this issue when behind my work's corporate proxy, and I'm fairly certain this is not a cargo issue.

In my case, the intermediate certificate used by the proxy lists an internal OCSP server, and the OCSP server returns "unauthorized" when attempting to check whether that certificate is revoked. In other words, it's a misconfiguration of the OCSP server.

I've verified that using the following command:

openssl ocsp -issuer .\crates-io-chain.pem -cert .\crates-io.pem -text -url <ocsp_server_url> -no_nonce

This command returns success when used to check the original certificates against the original OCSP server, but returns an "unauthorized" error when checking the proxy certificate against its own OCSP server.

[thisisscotts]

Like the OP, I'm also behind a corporate firewall and have tried a number of different options within VSCode or adding certificates to my machine to no avail. In the end, I implemented @alexcrichton 's solution:

# in .cargo/config.toml
[http]
check-revoke = false

Obviously this is not ideal, but it took me a long time to work out that it was Cargo that was having issues getting the revocation info from my corp environment.

[xenoworf]

I had this problem, and the correct resolution is to have your network admin exempt crates.io from SSL decryption. Doing so will stop the error because there is no more MITM'ing and preserves revocation checks for better sec.