Kubernetes "certificate signed by unknown authority": kubeconfig debugging

Fix kubectl "certificate signed by unknown authority"

TL;DR

The CA bundled in your kubeconfig does not match the CA that signed the API server's certificate. Get a fresh kubeconfig from your cluster admin or cloud console, or fix the certificate-authority-data entry for that cluster. kubectl pins the cluster CA in the kubeconfig, so any mismatch fails the TLS handshake before auth even starts.

Kubernetes "certificate signed by unknown authority": kubeconfig debugging

Steps

1. Identify the broken context. Run kubectl config get-contexts and kubectl config current-context.

Expected: you know exactly which cluster entry fails.

1. Inspect the cluster entry. Run kubectl config view and look at the certificate-authority-data (or certificate-authority file path) for that cluster.

Expected: you see the CA data present, missing, or pointing at a stale file.

1. Get a fresh kubeconfig. Regenerate it from your cloud console, cluster admin, or the provider CLI for your platform.

Expected: the new file carries the current CA and kubectl connects.

1. If the cluster CA was rotated, expect this. Old kubeconfigs break by design after rotation. Distribute the new CA to everyone and everything that talks to the cluster.

Expected: kubectl works everywhere again once the new CA is in place.

1. If you sit behind a TLS-intercepting proxy, fix trust properly. Add the proxy's CA to your system trust store rather than hacking the kubeconfig.

Expected: kubectl trusts the full chain through the proxy.

Use this when

• kubectl fails with x509: certificate signed by unknown authority
• A kubeconfig that used to work suddenly stops after a cluster upgrade
• Setting up kubectl on a new machine against an existing cluster

Not for this skill when

• The error says the certificate has expired (different fix: renew, not replace CA)
• Auth fails with token or credential errors (the TLS handshake already succeeded)
• The error is "connection refused" (the API server is not reachable at all)

Variant phrasings

• kubectl x509 certificate signed by unknown authority
• kubeconfig ca mismatch
• unknown authority kubernetes
• kubectl certificate authority invalid

Why it happens

Every cluster has a certificate authority that signs the API server's serving certificate. kubectl verifies that serving cert against the CA pinned in the kubeconfig. Rotation, a copied kubeconfig from another cluster, or a proxy inserting its own cert all break that pin, and TLS fails closed.

Edge cases

• An expired CA produces a nearly identical error. Check the CA dates before assuming mismatch.
• Multiple contexts across merged kubeconfig files get mixed up easily. Always verify current-context first.
• Some tools cache the old CA or the old kubeconfig. Restart them after replacing the file.
• Service account tokens mounted in pods use the cluster's own CA bundle, so in-cluster clients are unaffected by your local kubeconfig problem.

Provenance

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