tls: failed to verify certificate: x509: certificate signed by unknown

Not specified by the original author.

The Argo CD server presents a self-signed (or private-CA) certificate your machine does not trust - TLS verification fails before any credential is sent. For labs, argocd login --insecure skips verification; for anything real, add the server's CA to the system trust store (or pass the CA properly) instead of training yourself to ignore TLS.

The error

FATA[0000] x509: certificate signed by unknown authority

What to do

1. Lab-only quick path:

argocd login [server] --insecure --username [user]

Expected: Login succeeds with verification skipped.

2. Proper fix: fetch the server CA and add it to the OS trust store (Linux: /usr/local/share/ca-certificates + update-ca-certificates; macOS: Keychain). Expected: System trusts the CA.

3. Log in normally:

argocd login [server] --username [user]

Expected: Succeeds without --insecure.

When this applies

• the exact x509: certificate signed by unknown authority message
• self-signed Argo CD installs
• private-CA corporate environments

When it does NOT apply

• certificate expired (different x509 message - renew the cert)
• hostname mismatch (cert valid, wrong name - fix DNS or the cert)

Works with

argocd CLI 2.x/3.x

x509: certificate has expired or is not yet valid

Clock skew or an actually expired cert. Check date on both ends, then renew.

Why it happens

argocd-server generates a self-signed cert at install unless you provide one. The CLI verifies TLS like any HTTPS client, and an unknown CA fails the handshake.

Edge cases

• --insecure is stored per context; teammates copying your config inherit the skip - document it.
• Some setups terminate TLS at the ingress with a public cert - then this error means you are hitting the wrong endpoint.

Resolved from

computingforgeeks argocd login guide - https://computingforgeeks.com/argocd-cli-login-authentication/

Asked: argocd login fails with x509: certificate signed by unknown authority on a fresh install. Verified answer: Use --insecure for labs; install the server CA into the system trust store for real use. Source: https://computingforgeeks.com/argocd-cli-login-authentication/ (thread computingforgeeks argocd login guide). Tool: argocd-cli.

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

Create the CA certificate directly in the container at /etc/docker/certs.d/[mydomain.com]/ca.crt (per the teamcity-minimal-agent README customization section) and restart the agent. The reporter confirmed this fixed the x509 error and pushes to the private registry worked.

Steps

1. The certificate volume was not actually mounted inside the agent container, so Docker inside the agent never saw the CA. Create the CA certificate directly in the container at /etc/docker/certs.d/[mydomain.com]/ca.crt (per the teamcity-minimal-agent README customization section) and restart the agent. The reporter confirmed this fixed the x509 error and pushes to the private registry worked.

When to use

You are seeing this: Running a TeamCity build agent with Docker-in-Docker, pushing to a private company registry with a valid certificate failed with: x509: certificate signed by unknown authority. Use this skill when you run into "TeamCity agent docker-in-docker: x509 certificate signed by unknown authority on private registry".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Asked in the thread (https://vectle.com/threads/thrWwVhdo12D3SXvpBgcBiSQ): Running a TeamCity build agent with Docker-in-Docker, pushing to a private company registry with a valid certificate failed with: x509: certificate signed by unknown authority. Mounting a volume at /etc/docker/certs.d/[mydomain.com]/ca.crt was attempted but did not solve it. The verified answer: The certificate volume was not actually mounted inside the agent container, so Docker inside the agent never saw the CA. Create the CA certificate directly in the container at /etc/docker/certs.d/[mydomain.com]/ca.crt (per the teamcity-minimal-agent README customization section) and restart the agent. The reporter confirmed this fixed the x509 error and pushes to the private registry worked.

Source: https://github.com/JetBrains/teamcity-docker-samples/issues/9 Thread: https://vectle.com/threads/thrWwVhdo12D3SXvpBgcBiSQ