kubectl: x509: certificate signed by unknown authority

Hi, it's BlueByte. You run a normal kubectl get pods and instead of your workloads you get Unable to connect to the server: x509: certificate signed by unknown authority. Nothing on the cluster is down — kubectl reached the API server, checked the TLS certificate it presented, and refused to trust it. We'll walk through the message variants, why the certificate authority in your kubeconfig stopped matching, how to see the certificate the server is really sending, how to fix it per cause, and how to keep it from coming back.

The x509 errors kubectl actually prints

Three related messages all come from the same TLS check. The most common one:

Unable to connect to the server: x509: certificate signed by unknown authority

kubectl connected, the API server sent its serving certificate, and kubectl couldn't trace that certificate back to the certificate authority (CA) recorded in your kubeconfig. Two close relatives show up too:

Unable to connect to the server: x509: certificate has expired or is not yet valid
Unable to connect to the server: x509: certificate is valid for 10.96.0.1, not 192.168.49.2

The first means the server's certificate is outside its validity window; the second means the certificate is genuine but was issued for a different name or IP than the server: address you're dialing. All three are kubectl declining to trust the endpoint — not the cluster being broken.

Why the CA stopped matching

A few concrete causes produce the "unknown authority" form:

• The cluster was rebuilt or its certificates were regenerated — minikube delete && minikube start, a recreated kind cluster, or a re-provisioned managed cluster all mint a new CA, but your kubeconfig still carries the old certificate-authority-data.
• You're pointed at the wrong cluster — a stale current-context, or a server: that resolves to a load balancer or proxy in front of a different API server.
• A corporate TLS-inspecting proxy sits between you and the server, re-signing the connection with a CA your machine trusts for browsers but kubectl does not.
• The kubeconfig has no CA at all for a self-signed server, so kubectl has nothing to verify against.

See which server and CA your kubeconfig is using

Don't guess which context is active — ask kubectl:

kubectl config view --minify

clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.49.2:8443
  name: minikube
current-context: minikube

--minify collapses the output to just the current context, so you see the exact server kubectl is dialing and whether a CA is embedded. kubectl config get-contexts lists every context, so you can confirm you're on the one you meant rather than a leftover from another cluster.

Read the certificate the server is really presenting

See what the endpoint actually sends, straight from OpenSSL:

openssl s_client -connect 192.168.49.2:8443 -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

issuer=CN=kubernetes
subject=CN=kube-apiserver
notBefore=... notAfter=...

If the issuer is your company's proxy CA instead of the cluster CA, you've found a MITM proxy in the path. If notAfter is in the past, the certificate expired. If the issuer looks right but kubectl still rejects it, the CA embedded in your kubeconfig is stale.

Fix it by cause: refresh the kubeconfig or embed the right CA

For a rebuilt or managed cluster, pull a fresh kubeconfig from the source of truth rather than hand-editing base64:

minikube update-context                                # minikube
aws eks update-kubeconfig --name mycluster             # EKS
gcloud container clusters get-credentials mycluster    # GKE

For a self-managed cluster, point the context at the correct CA file and embed it so it travels with the config:

kubectl config set-cluster mycluster \
  --server=https://192.168.49.2:8443 \
  --certificate-authority=/path/to/ca.crt \
  --embed-certs=true

For a corporate proxy, add the proxy's CA to the bundle kubectl reads, or route the API endpoint around inspection — don't disable verification globally. As a dev-only last resort you can skip the check, but understand it turns off exactly the protection the error provides:

kubectl config set-cluster mycluster --insecure-skip-tls-verify=true

A real case: a rebuilt minikube cluster

I ran minikube delete && minikube start to reset a broken local cluster, then kubectl get pods threw x509: certificate signed by unknown authority. kubectl config view --minify showed the same server: https://192.168.49.2:8443, so the address was fine — but the fresh cluster had a new CA the cached kubeconfig didn't know. minikube update-context rewrote the certificate-authority and client cert for the context, and the next kubectl get pods returned the node list. Under a minute, and no editing of base64 blobs by hand.

How it differs from Unauthorized and connection refused

x509: ... is about the server's identity — it fails during the TLS handshake, before you're ever authenticated. error: You must be logged in to the server (Unauthorized) is the opposite: the TLS check passed, but your credentials were rejected. The connection to the server ... was refused is earlier still — nothing answered on the API port, so there was no certificate to check. Reading which of the three you got tells you whether to look at the CA, at your credentials, or at whether the server is up at all.