http.check-revoke controls certificate revocation checking on Windows. Setting it to false changes validation policy. It does not discover a proxy, select its protocol or install your organization's CA.

That is why a recipe containing both a proxy URL and check-revoke = false needs to be read as two separate changes. If disabling the check changes the outcome, you have a lead in certificate verification—not proof that the proxy route was repaired.

Use the original error to decide the next investigation. A revoked certificate, unavailable revocation information and an unrelated chain failure are different findings. For unavailable status information, trace the verifier's retrieval route and proxy authentication under the Windows account running Cargo, with its actual TLS backend.

Also identify the failed download. Cargo's HTTP transfers and a separate Git invocation can have different configuration. A successful retry on one path says nothing about the other's certificate policy.

Keep required verification enabled while repairing retrieval and trust. If an organization intentionally disables revocation checking, record that as a policy decision rather than a general proxy compatibility setting.

Related articles