x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")

kubectl 会把它打印在“Unable to connect to the server: tls: failed to verify certificate: ”之后。对于 ECDSA CA，内部原因则是“x509: ECDSA verification failure”，而不是“crypto/rsa: verification error”；引号中的名称是 CA 的通用名称。

kubectl and other Go clients — a CA with the right name but the wrong key (e.g. a kubeconfig from before kubeadm reset)

含义

Go 在你的信任配置中找到了一个名称与服务器证书颁发者相符的 CA（在 kubeadm 集群中为“kubernetes”），并用它尝试验证，但用该 CA 的密钥验证签名没有通过。两个不同的 CA 同名：一个在你的 kubeconfig 中，另一个才是真正签发 API 服务器证书的 CA。这是重建集群（kubeadm reset 后再 init）却保留旧 ~/.kube/config 时的典型结果。

原因

• 集群用 kubeadm 重新创建过

  常见

  kubeadm init 每次都会生成一个名为“kubernetes”的新 CA；而上一个集群的 kubeconfig 中仍内嵌着同名的旧 CA。

• 旧的 ~/.kube/config 或 KUBECONFIG 条目

  常见

  多个本地集群（kind、minikube、k3d）以相同的上下文名称重新创建后，会留下过时的 CA 数据。

• 集群 CA 已轮换

  偶见

  CA 轮换之后，没有拿到新 CA 证书包的客户端会一直这样报错，直到它们的 kubeconfig 更新为止。

修复方法

1. 1.

   确认两个 CA 的密钥不同

   名称相同而公钥哈希不同，就证明 kubeconfig 中保存的是另一个集群的 CA。

   # Same name, different key? Compare the public keys of the two CAs
   kubectl config view --minify --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' \
     | base64 -d | openssl x509 -noout -pubkey | openssl sha256
   sudo openssl x509 -in /etc/kubernetes/pki/ca.crt -noout -pubkey | openssl sha256   # on a control-plane node

2. 2.

   使用新集群的 kubeconfig

   执行 kubeadm init 之后，复制 /etc/kubernetes/admin.conf（或者重新生成用户的 kubeconfig），让内嵌的 CA 与新集群匹配。

   # After kubeadm init/reset: replace the old kubeconfig with the new admin.conf
   mkdir -p "$HOME/.kube"
   sudo cp /etc/kubernetes/admin.conf "$HOME/.kube/config"
   sudo chown "$(id -u):$(id -g)" "$HOME/.kube/config"

3. 3.

   检查实际生效的是哪个 kubeconfig

   KUBECONFIG 中可能列出了多个文件；以第一个定义了该上下文的文件为准。

   # Make sure no other kubeconfig overrides it
   echo "$KUBECONFIG"; kubectl config current-context

← 浏览完整的签名错误库