trivy fails with x509: certificate signed by unknown authority when down

Not specified by the original author.

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 SSLCERTFILE at the CA bundle before running trivy. Then confirm the DB downloads with a standalone fetch before the next scan.

The query

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

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):

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

Option B, environment variable (per run):

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

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 SSLCERTFILE 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 SSLCERTFILE approach there.

Provenance

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

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

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

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 SSLCERTFILE at the CA bundle before running trivy. Then confirm the DB downloads with a standalone fetch before the next scan.

Not specified by the original author.

TL;DR: Give the daemon the registry CA certificate: copy the CA cert to /etc/docker/certs.d/[registry-host]/ca.crt and restart docker. The daemon validates registry TLS against the host trust store plus per-registry cert dirs; a private CA is unknown until you install it there.

The error

Error response from daemon: Get "https://registry.example.com:5000/v2/": x509: certificate signed by unknown authority

Fix it

1. Get the CA certificate (PEM) from your registry admin.

2. Place it where the daemon looks: sudo mkdir -p /etc/docker/certs.d/registry.example.com:5000 && sudo cp ca.crt /etc/docker/certs.d/registry.example.com:5000/ca.crt Expected: file in place, owned by root.

3. Restart the daemon: sudo systemctl restart docker

4. Retry the pull: docker pull registry.example.com:5000/myimage:tag Expected: succeeds.

When this applies

• Self-hosted registries with internal CA or self-signed certs
• Corporate MITM proxies re-signing registry traffic

When this does NOT apply

• Public registries (their certs chain to public roots; check your clock/proxy instead)
• "http: server gave HTTP response to HTTPS client" (plain HTTP registry, different fix)

Versions

All Docker versions.

Why it happens

The daemon does full TLS verification on registry connections. Internal CAs are not in the default trust bundle, so verification fails before any HTTP happens.

Edge cases

• The directory name must match the registry host AND port exactly (YOUR_REGISTRY_HOST:5000).
• Docker Desktop: put certs in the VM via Settings, or mount; /etc/docker/certs.d on the Mac host is not read by the VM daemon.
• Expired certs give a different x509 message ('certificate has expired'); renew instead of reinstalling CA.
• As a last resort, "insecure-registries" in daemon.json skips verification, but it disables TLS checks entirely; prefer installing the CA.

Asked: how to fix x509: certificate signed by unknown authority (pulling from a private registry). Verified answer: Fixes 'x509: certificate signed by unknown authority' against private registries with self-signed or internal CA certs. Use when the daemon distrusts the registry TLS certificate. The fix steps above were cross-checked against the accepted community answer at https://stackoverflow.com/questions/64462922/docker-multi-stage-build-go-image-x509-certificate-signed-by-unknown-authorit (so:64462922), which confirms the same resolution.

Not specified by the original author.

TL;DR: Point trivy at the new database mirror location, clear the stale cached database, and let it re-download. Trivy refuses to scan without a current vulnerability database, so a moved mirror is a hard stop, not a warning. If egress is restricted, download the database once on an allowed host and run the scan offline.

FATAL failed to download vulnerability DB

1. Check the database cache age: look in trivy's cache directory for the database files and note their timestamps. Expected: the cache is stale or missing, confirming the download is the failure point.
2. Update the database mirror setting to the new location (the TRIVYDBREPOSITORY setting), or remove the override if the default moved. Expected: the setting names a reachable mirror.
3. Clear the stale cache so trivy performs a clean download. Expected: the cache directory no longer holds the old database files.
4. Re-run the scan and watch the first lines of output. Expected: the vulnerability database download completes and the scan proceeds.
5. For locked-down networks, download the database tarball on a host with egress, copy it in, and run the scan with the offline-scan flag. Expected: the scan runs with no network calls.

Use this when

• trivy fails before scanning with a database download error
• the database mirror moved or changed URL
• scans worked before a mirror change and broke after
• trivy reports a stale or missing vulnerability database

Not for this skill when

• trivy downloads the database fine but fails mid-scan
• the error concerns the Java database or another component
• the failure is a TLS certificate error behind a proxy (a proxy problem, not a mirror problem)
• you want fully offline scanning by design (use the offline step instead)

Variant phrasings

• trivy FATAL vulnerability DB download failed
• trivy cannot download vulnerability database
• trivy db mirror moved
• trivy failed to download db

Why it happens

Trivy downloads its vulnerability database from a mirror on first run and on refresh. When the mirror moves, the old URL returns 404 or times out, and trivy treats a missing database as fatal because every finding depends on it.

Edge cases

• corporate proxies that intercept TLS break the download with a certificate error, not a 404 - that is a proxy problem, not a mirror problem
• a partially downloaded database corrupts the cache - always clear before retrying
• air-gapped setups need the database refreshed on a schedule, or findings silently age out
• pinning trivy and the database version together avoids format mismatches after upgrades

Provenance

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

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

Thread query: trivy: "FATAL failed to download vulnerability DB" after the db mirror moved

TL;DR: