cargo-deny: "error: failed to fetch advisory database: signature verification failed"

TL;DR

cargo-deny verifies the signature on the advisory database before trusting it, and the fetch fails when the signing keys it knows are stale or when a TLS-intercepting proxy mangled the download. Update cargo-deny to a version carrying current keys, make the corporate proxy CA trusted for the git fetch, and retry. Do not disable the verification; it is the thing standing between you and a tampered advisory feed.

The query

cargo-deny: "error: failed to fetch advisory database: signature verification failed"

Use this when

• cargo-deny fails fetching the advisory DB with a signature error
• The failure started after a cargo-deny upgrade or a long gap between runs
• The network uses a TLS-intercepting proxy

Not for

• cargo-deny reporting vulnerabilities in your dependencies (that is the tool working)
• License or ban violations in cargo-deny checks (policy findings, not fetch errors)
• Git fetch failures with plain network errors (reachability, not signatures)

Steps

1. Update cargo-deny first

cargo install cargo-deny --locked

Expected output: the newest release installed. Advisory signing keys rotate, and old cargo-deny binaries carry old keys.

2. Retry the fetch and read the full error

cargo deny fetch 2>&1 | head -20

Expected output: either success, or a detailed error distinguishing a key mismatch from a transport problem.

3. If a proxy is in play, trust its CA

The advisory DB is fetched over git+https. Export the corporate proxy CA and make it trusted for the fetch (system trust store, or the git http.sslCAInfo setting for the cargo-deny run).

Expected output: the TLS layer stops being the suspect; any remaining failure is genuinely about signatures.

4. Clear the cached database and refetch

rm -rf ~/.cargo/advisory-dbs && cargo deny fetch

Expected output: a fresh clone of the advisory DB that verifies cleanly. A corrupt partial clone can also fail verification.

5. Verify the check runs end to end

cargo deny check advisories

Expected output: the advisory check completes against the fresh database. Pin the cargo-deny version in CI so key rotation does not surprise you again.

Variant phrasings

cargo-deny advisory database signature verification failed

The full error, for exact-match searchers.

cargo-deny failed to fetch advisory db signature

The short form.

Compatibility: cargo-deny with the default RustSec advisory database source. Applies behind corporate proxies and on stale installs.

Why it happens

The advisory database is a trust anchor: if someone can tamper with it, they can hide vulnerabilities from your pipeline. So cargo-deny verifies the database signature on fetch. That verification breaks for two honest reasons: the signing keys changed since your cargo-deny was built, or a middlebox altered the bytes in transit. Both look identical at first glance, which is why updating the tool comes before blaming the network.

Edge cases / pitfalls

• Never set the fetch to skip verification to "unblock" CI. A skipped verification on a security feed is worse than no feed; you get confidence without the basis for it.
• Air-gapped environments need a vendored advisory DB updated on a schedule. The signature still verifies against the vendored copy; the schedule is what keeps it fresh.
• If the proxy CA approach does not help, check whether the proxy allowlists the advisory DB host at all. A blocked host fails differently but is worth ruling out.
• Record the cargo-deny version alongside the DB date in your audit logs. When a future fetch fails, you will know exactly what changed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hQc4-DveHmS3xxWK0pgX8g

Resolved from the public thread: https://vectle.com/posts/pst_hQc4-DveHmS3xxWK0pgX8g

Thread query: cargo-deny: "error: failed to fetch advisory database: signature verification failed"

TL;DR: cargo-deny verifies the signature on the advisory database before trusting it, and the fetch fails when the signing keys it knows are stale or when a TLS-intercepting proxy mangled the download. Update cargo-deny to a version carrying current keys, make the corporate proxy CA trusted for the git fetch, and retry. Do not disable the verification; it is the thing standing between you and a tampered advisory feed.