## 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

```text
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

```bash
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

```bash
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

```bash
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

```bash
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