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

kubectl lo imprime después de «Unable to connect to the server: tls: failed to verify certificate: ». Con CA ECDSA, el motivo interno dice «x509: ECDSA verification failure» en lugar de «crypto/rsa: verification error»; el nombre entre comillas es el nombre común de la CA.

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

Qué significa

Go encontró en tu configuración de confianza una CA cuyo nombre coincide con el emisor del certificado del servidor («kubernetes» en los clústeres de kubeadm), la probó, y la firma no se pudo verificar con la clave de esa CA. Dos CA distintas comparten el mismo nombre: la de tu kubeconfig y la que firmó realmente el certificado del servidor de API. Es el resultado clásico de reconstruir un clúster (kubeadm reset e init) conservando el antiguo ~/.kube/config.

Por qué ocurre

• El clúster se volvió a crear con kubeadm

  frecuente

  kubeadm init genera cada vez una CA nueva llamada «kubernetes»; el kubeconfig del clúster anterior sigue llevando incrustada la CA antigua con el mismo nombre.

• Un ~/.kube/config o una entrada de KUBECONFIG antiguos

  frecuente

  Varios clústeres locales (kind, minikube, k3d) recreados con el mismo nombre de contexto dejan datos de CA obsoletos.

• Se rotó la CA del clúster

  ocasional

  Tras una rotación de la CA, los clientes que no recibieron el nuevo bundle de CA fallan así hasta que se actualiza su kubeconfig.

Cómo solucionarlo

1. 1.

   Confirmar que las claves de las CA son distintas

   Nombres iguales con hashes de clave pública distintos demuestran que el kubeconfig contiene la CA de otro clúster.

   # 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.

   Usar el kubeconfig del clúster nuevo

   Después de kubeadm init, copia /etc/kubernetes/admin.conf (o vuelve a generar los kubeconfig de los usuarios) para que la CA incrustada coincida con la del clúster nuevo.

   # 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.

   Comprobar qué kubeconfig está en uso

   KUBECONFIG puede enumerar varios archivos; prevalece el primero que define el contexto.

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

← Explorar toda la base de datos de errores de firma