# x509: certificate signed by unknown authority（kubectl）怎么修

> kubectl 报 x509: certificate signed by unknown authority，通常是 kubeconfig 里的 CA 和 API Server 证书对不上。重新获取 kubeconfig，不要跳过 TLS 校验。

Source: https://ssl.sh/zh/errors/kubectl-x509-certificate-signed-by-unknown-authority/
Last updated: 2026-11-10

**`Unable to connect to the server: x509: certificate signed by unknown authority` 的意思是：kubectl 用 kubeconfig 里保存的 CA 验证不了 Kubernetes API Server 的证书。** 大多数情况是 kubeconfig 过期（集群重装或 CA 轮换过）、指向了错误的集群，或者连接经过了出示别的证书的代理或负载均衡。

较新的 kubectl 会显示 `tls: failed to verify certificate: x509: certificate signed by unknown authority`，是同一个错误。

## 快速修复

kubeconfig 里的 [CA](https://ssl.sh/zh/glossary/certificate-authority/) 和 API Server 证书的签发者对不上时，修法是重新获取 kubeconfig。先对比两者：

```bash
# 当前 context 的 kubeconfig 里的 CA
kubectl config view --minify --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' \
  | base64 -d | openssl x509 -noout -subject -fingerprint -sha256

# 服务器地址，以及它出示的证书链
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'; echo
openssl s_client -connect 203.0.113.10:6443 -showcerts </dev/null | grep -E 's:|i:'
```

如果服务器证书的签发者不是 kubeconfig 里的那张 CA，就重新获取 kubeconfig：

- **kubeadm 集群：** 从控制平面节点把 `/etc/kubernetes/admin.conf` 复制到 `~/.kube/config`。
- **托管集群：** 到云厂商控制台或命令行工具里重新下载 kubeconfig。阿里云 ACK、腾讯云 TKE 都在集群详情的“连接信息”里提供 kubeconfig，注意区分公网和内网访问的两份配置。
- **手上只有 CA 文件：** 把它嵌入 cluster 条目：

```bash
kubectl config set-cluster my-cluster --certificate-authority=ca.crt --embed-certs=true
```

## 原因

多数情况是集群重建或 CA 轮换后，kubeconfig 里还是旧的 CA。

### 1. 集群重建或 CA 轮换后 kubeconfig 没更新

- **确认：** kubeconfig 里 CA 的指纹和服务器证书签发 CA 的指纹不一样，集群最近重装过。
- **修复：** 按上面替换 kubeconfig。别忘了 CI 构建机、同事电脑上的 kubeconfig 也一起过期了。

### 2. context 选错，或合并的 kubeconfig 串了

一个文件里有多个集群，或者 `KUBECONFIG` 列了多个文件时，某个 cluster 条目可能带着另一个集群的 CA。

- **确认：** `kubectl config current-context` 和 `kubectl config view --minify` 显示实际用的是哪个条目。
- **修复：** 用 `kubectl config use-context` 切换，或修正 cluster 条目。

### 3. 走了代理

kubectl 会读取 `HTTPS_PROXY`。解密 HTTPS 的[公司代理](https://ssl.sh/zh/errors/corporate-ssl-inspection/)会把 API Server 的证书换成自己的。

- **确认：** `env | grep -i proxy`；在同一个 shell 里执行 `openssl s_client`，签发者是代理设备。
- **修复：** 把 API Server 地址加进 `NO_PROXY`，让 kubectl 直连。

### 4. 负载均衡终结了 TLS

API Server 前面的负载均衡如果出示自己的证书，kubectl 看到的就不是集群 CA 签发的证书。

- **修复：** 6443 端口改用四层（TCP）透传，让 API Server 自己的证书直达客户端；或者在 kubeconfig 里改用负载均衡的 CA（但此时经过终结 TLS 的负载均衡，客户端证书认证就无法使用）。自建集群用阿里云 SLB、腾讯云 CLB 做高可用时，应选 TCP 监听而不是 HTTPS 监听。

## 各环境修法

目标是让 kubeconfig 里的 CA 和 API Server 证书的签发者一致，各发行版的区别只在 CA 文件从哪里取。

**kubeadm：** 集群 CA 是 `/etc/kubernetes/pki/ca.crt`，`admin.conf` 里嵌入了它以及一张管理员客户端证书。

**托管 Kubernetes：** 用云厂商提供的工具重新生成凭证，不要手工改 CA 数据。

**集群内的 Pod 和 Webhook：** API Server 调用准入 Webhook 时报类似错误，说明 Webhook 的 `caBundle` 和它的服务证书对不上。由 cert-manager 管理时检查对应的 `Certificate` 资源，见 [cert-manager 证书未就绪](https://ssl.sh/zh/errors/cert-manager-certificate-not-ready/)。

**其他 Go 工具：** Helm、k9s、Lens 以及 Terraform 的 Kubernetes provider 读的是同一份 kubeconfig，修一次全部生效。通用的 Go 报错见 [x509: certificate signed by unknown authority](https://ssl.sh/zh/errors/x509-certificate-signed-by-unknown-authority/)。

## 不要这样做

下面的做法都会让 kubectl 把集群管理员凭据交给未经验证的服务器。

- **`kubectl --insecure-skip-tls-verify`，或在 kubeconfig 里写 `insecure-skip-tls-verify: true`。** 你的客户端证书或 Token 会交给任何应答的一方，而这些凭证通常就是集群管理员权限。
- **删掉 `certificate-authority-data`，指望退回系统证书库。** 集群 CA 是私有的，这样照样失败，还容易让人为内部地址去信任公网 CA。
- **为了省事在微信群、邮件里传同一份管理员 kubeconfig。** 应该为每个人生成各自的凭证。