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

kubectl gibt die Meldung nach „Unable to connect to the server: tls: failed to verify certificate: “ aus. Bei ECDSA-CAs lautet der innere Grund „x509: ECDSA verification failure“ statt „crypto/rsa: verification error“; der Name in Anführungszeichen ist der Common Name der CA.

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

Was der Fehler bedeutet

Go hat in deiner Vertrauenskonfiguration eine CA gefunden, deren Name zum Aussteller des Serverzertifikats passt („kubernetes“ in kubeadm-Clustern), und sie ausprobiert, doch die Prüfung der Signatur mit dem Schlüssel dieser CA ist fehlgeschlagen. Zwei verschiedene CAs tragen denselben Namen: die in deiner kubeconfig und die, die das Zertifikat des API-Servers tatsächlich signiert hat. Das ist die klassische Folge, wenn ein Cluster neu aufgebaut wird (kubeadm reset und init), die alte ~/.kube/config aber bleibt.

Warum der Fehler auftritt

• Der Cluster wurde mit kubeadm neu angelegt

  häufig

  kubeadm init erzeugt jedes Mal eine neue CA namens „kubernetes“; die kubeconfig des vorherigen Clusters enthält noch die alte CA mit demselben Namen.

• Eine alte ~/.kube/config oder ein alter KUBECONFIG-Eintrag

  häufig

  Mehrere lokale Cluster (kind, minikube, k3d), die unter demselben Kontextnamen neu angelegt wurden, hinterlassen veraltete CA-Daten.

• Die Cluster-CA wurde rotiert

  gelegentlich

  Nach einer CA-Rotation scheitern Clients, die das neue CA-Bundle nicht bekommen haben, auf diese Weise, bis ihre kubeconfig aktualisiert ist.

So behebst du den Fehler

1. 1.

   Bestätigen, dass sich die CA-Schlüssel unterscheiden

   Gleiche Namen bei unterschiedlichen Hashes der öffentlichen Schlüssel beweisen, dass die kubeconfig die CA eines anderen Clusters enthält.

   # 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 des neuen Clusters verwenden

   Kopiere nach kubeadm init die Datei /etc/kubernetes/admin.conf (oder erzeuge die kubeconfigs der Benutzer neu), damit die eingebettete CA zum neuen Cluster passt.

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

   Prüfen, welche kubeconfig gilt

   KUBECONFIG kann mehrere Dateien auflisten; es gilt die erste, die den Kontext definiert.

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

← Gesamte Signaturfehler-Datenbank durchsuchen