## TL;DR
Your corporate proxy terminates TLS and re-signs it with its own CA, which trivy's certificate pool does not trust. The fix is to make that CA trusted: install the proxy's CA certificate into the OS trust store, or point SSL_CERT_FILE at the CA bundle before running trivy. Then confirm the DB downloads with a standalone fetch before the next scan.

## The query

```text
trivy fails with "x509: certificate signed by unknown authority" when downloading the vulnerability DB behind a TLS-intercepting proxy
```

## Use this when

- trivy fails on the DB download step with an x509 error, and the network runs a TLS-intercepting proxy
- The same scan works off the corporate network or VPN
- curl to the DB host also fails with a certificate complaint

## Not for

- "FATAL failed to download vulnerability DB" with a DNS or connection timeout (reachability, not trust)
- Registry pull failures with "unauthorized" (authentication, not TLS)
- An expired or revoked certificate on a host you control (fix the cert, not the trust store)

## Steps

### 1. Prove it is the proxy, not trivy

```bash
curl -sI https://aquasecurity.github.io | head -5
```

Expected output: a curl certificate error naming the issuer. If curl succeeds but trivy fails, the gap is trivy's cert pool, not the proxy.

### 2. Get the proxy CA certificate

Ask your IT team for the proxy's root CA in PEM format, or export it from your workstation's certificate store. Save it where the scan runner can read it.

Expected output: a PEM file starting with the BEGIN CERTIFICATE marker.

### 3. Make the CA trusted for the scan

Option A, OS store (persistent on the runner):

```bash
cp corp-proxy-ca.pem /usr/local/share/ca-certificates/ && update-ca-certificates
```

Option B, environment variable (per run):

```bash
export SSL_CERT_FILE=/path/to/corp-proxy-ca.pem
```

Expected output: curl to the DB host now completes without a certificate error.

### 4. Warm the DB as a standalone step

```bash
trivy image --download-db-only
```

Expected output: trivy reports the vulnerability DB downloaded and updated, with no x509 error.

### 5. Bake the fix into the pipeline

Add the CA install to the runner image or the pipeline's setup step so every future run trusts the proxy from the start. Verify: a fresh runner with an empty cache completes a trivy scan on a small test image.

## Variant phrasings

### trivy x509 certificate signed by unknown authority
The short form of this error, same fix.

### trivy vulnerability DB download fails behind corporate proxy
Symptom-level phrasing from operators who have not read the x509 line yet.

Compatibility: trivy 0.4x and later, which fetch the vulnerability DB over HTTPS from the public mirror. Go's TLS stack honors SSL_CERT_FILE and the OS trust store.

## Why it happens
A TLS-intercepting proxy sits between trivy and the DB mirror, presenting a certificate signed by a corporate CA that trivy's bundled certificate pool does not know. Trivy correctly refuses the connection because the chain does not anchor to a trusted root. Both sides are working as designed; the missing piece is the corporate CA in trivy's trust path.

## Edge cases / pitfalls

- The proxy CA rotates. When DB downloads break again months later, check the CA expiry date before debugging anything else.
- An allowlist-only egress proxy can also block the DB mirror host outright. If trusting the CA still fails, confirm the mirror host is on the allowlist.
- Do not reach for any "skip TLS verification" workaround. You would trade a visible trust problem for an invisible one.
- Minimal container images often lack update-ca-certificates. Use the SSL_CERT_FILE approach there.

## Provenance

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