cargo audit: "error: failed to download advisory database: SSL certificate verify failed" behind a MITM proxy

Fix cargo audit "SSL certificate verify failed" behind a MITM proxy

TL;DR

Your corporate proxy re-signs HTTPS traffic with its own certificate, and cargo does not trust that certificate authority. Point cargo at your proxy's CA bundle in its config so TLS verification passes. The fetch then completes and the audit runs.

cargo audit: "error: failed to download advisory database: SSL certificate verify failed" behind a MITM proxy

Steps

1. Confirm the proxy is the cause. Check that other tools also fail on HTTPS unless they are configured with the company CA.

   • Run: curl -I https://static.crates.io
   • Expected: curl succeeds only when given the company CA, or fails with a similar certificate error, confirming the proxy re-signs traffic.

2. Locate your organization's proxy CA certificate file (usually a .pem or .crt your IT team distributes).

   • Run: ls [PATH TO YOUR COMPANY CA FILE]
   • Expected: the CA bundle file exists and is readable.

3. Tell cargo to trust that CA by setting the cafile entry under the http section of your cargo config.

   • Run: open ~/.cargo/config.toml and add a http section with a cafile entry pointing at the CA bundle file
   • Expected: the config file contains the http section with the cafile path (no other changes needed).

4. Re-run cargo audit and verify the database downloads.

   • Run: cargo audit
   • Expected: cargo audit fetches the advisory database with no SSL error and prints audit results.

Use this when

• cargo audit fails to download the advisory database with an SSL certificate verify error
• You are behind a corporate MITM/TLS-inspecting proxy
• curl and other tools show the same certificate error until given the company CA

Not for this skill when

• The advisory database parses but is invalid TOML (corrupted cache - clear it instead)
• The failure is a DNS or connection error, not a certificate error
• You do not use a proxy and the error is intermittent (check for captive portals or clock skew instead)

Variant phrasings

• cargo audit ssl error behind corporate proxy
• cargo audit certificate verify failed proxy
• rustsec database download ssl error

Why it happens

A TLS-inspecting proxy terminates your HTTPS connection and re-encrypts it with the proxy's own certificate, signed by the company's internal CA. Cargo's TLS stack trusts the system CA store by default, which does not include that internal CA, so verification of the re-signed connection fails. Pointing cargo's cafile at the company CA makes the proxy's certificate chain verifiable.

Edge cases

• The CA file path moves on managed laptops: keep the path in user-level config, not machine scripts, and re-check after IT pushes updates.
• cargo audit is run by a service account in CI: that account needs the same http cafile entry in its own cargo config.
• Your org rotates the proxy CA yearly: a sudden recurrence of this error after months of working usually means the CA file is stale, so re-download it from IT.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7zA2Zdcv0ZBLI2wPQggCDA