remote error: tls: bad certificate

Go-Server protokollieren „http: TLS handshake error from <client>: remote error: tls: bad certificate“. Clients auf OpenSSL-Basis senden für dieselbe Ablehnung andere Alerts (unknown_ca bei TLS 1.2), deshalb hängt der Text auf der Serverseite von der TLS-Bibliothek des Clients ab.

Go crypto/tls — TLS alert 42 received from the peer; typically logged by a Go server whose certificate a Go client rejected

Was der Fehler bedeutet

Die Gegenstelle hat den TLS-Alert 42 (bad_certificate) gesendet. Im Log eines Go-Servers („http: TLS handshake error from …: remote error: tls: bad certificate“) bedeutet das, dass ein Client das Zertifikat des Servers abgelehnt hat; Go-Clients senden diesen Alert bei jedem Fehlschlag der Prüfung (unbekannte Zertifizierungsstelle, Ablauf, falscher Name). In einem Go-Client bedeutet es, dass der Server bei Mutual TLS das Client-Zertifikat abgelehnt hat. Der eigentliche Grund ist nur auf der Seite sichtbar, die den Alert gesendet hat.

Warum der Fehler auftritt

• Ein Go-Client vertraut dem Zertifikat des Servers nicht

  häufig

  Selbstsignierte Zertifikate oder Zertifikate einer privaten CA, fehlende Zwischenzertifikate, abgelaufene Zertifikate oder ein falscher Name; das Log des Clients selbst zeigt „x509: …“.

• Mutual TLS: Der Server hat das Client-Zertifikat abgelehnt

  häufig

  Tritt auf der Client-Seite auf, wenn sein Zertifikat abgelaufen ist, von einer nicht vertrauenswürdigen CA ausgestellt wurde oder ihm die Verwendung clientAuth fehlt.

• Admission Webhooks und Operatoren in Kubernetes

  gelegentlich

  Der API-Server (ein Go-Client) lehnt das Zertifikat eines Webhooks ab, wenn das caBundle nicht passt; der Webhook-Server protokolliert das als bad certificate.

So behebst du den Fehler

1. 1.

   Ablehnenden Client finden und seinen Fehler lesen

   Die Client-Adresse im Log zeigt dir, welchen Dienst du dir ansehen musst; dessen Fehlermeldung nennt den tatsächlichen Grund, aus dem die Prüfung fehlgeschlagen ist.

   # The log line names the client; its own error message says why it rejected the certificate
   journalctl -u myservice | grep 'remote error: tls: bad certificate' | grep -oE 'from [0-9a-f.:]+' | sort | uniq -c

2. 2.

   Vollständige, vertrauenswürdige Kette ausliefern

   Gib dem Go-Server eine PEM-Datei mit der vollständigen Kette, ausgestellt von einer CA, der alle Clients vertrauen.

   // Serve the full chain: leaf first, then intermediates, in one PEM file
   log.Fatal(http.ListenAndServeTLS(":443", "fullchain.pem", "server.key", nil))

3. 3.

   Kubernetes: caBundle des Webhooks prüfen

   Das caBundle muss die CA enthalten, die das Serverzertifikat des Webhooks ausgestellt hat; der CA Injector von cert-manager hält beides synchron.

   # Kubernetes webhooks: the API server verifies the webhook's certificate with caBundle
   kubectl get validatingwebhookconfiguration my-webhook -o jsonpath='{.webhooks[0].clientConfig.caBundle}' \
     | base64 -d | openssl x509 -noout -subject -enddate

← Gesamte Signaturfehler-Datenbank durchsuchen