remote error: tls: bad certificate

Les serveurs Go consignent « http: TLS handshake error from <client>: remote error: tls: bad certificate ». Les clients fondés sur OpenSSL envoient d’autres alertes pour le même refus (unknown_ca en TLS 1.2) : le texte côté serveur dépend donc de la bibliothèque TLS du client.

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

Ce que cela signifie

Le pair a envoyé l’alerte TLS 42 (bad_certificate). Dans le journal d’un serveur Go (« http: TLS handshake error from …: remote error: tls: bad certificate »), elle signifie qu’un client a refusé le certificat du serveur ; les clients Go envoient cette alerte pour tout échec de vérification (autorité inconnue, expiration, mauvais nom). Côté client Go, elle signifie que le serveur a rejeté le certificat client en TLS mutuel. La raison réelle n’est visible que du côté qui a envoyé l’alerte.

Pourquoi cela se produit

• Un client Go ne fait pas confiance au certificat du serveur

  fréquente

  Certificats auto-signés ou émis par une AC privée, certificats intermédiaires manquants, certificats expirés ou mauvais nom ; le propre journal du client affiche « x509: … ».

• TLS mutuel : le serveur a rejeté le certificat client

  fréquente

  Visible côté client lorsque son certificat a expiré, a été émis par une AC non approuvée ou ne comporte pas l’usage clientAuth.

• Webhooks d’admission et opérateurs Kubernetes

  occasionnelle

  Le serveur d’API (un client Go) rejette le certificat d’un webhook lorsque le caBundle ne correspond pas, ce que le serveur du webhook consigne sous la forme « bad certificate ».

Comment corriger l’erreur

1. 1.

   Trouver le client qui refuse et lire son erreur

   L’adresse du client dans le journal vous indique quel service examiner ; son erreur précise l’échec de vérification réel.

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

   Servir une chaîne complète et approuvée

   Fournissez au serveur Go un fichier PEM contenant la chaîne complète, émise par une AC à laquelle tous les clients font confiance.

   // 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 : vérifier le caBundle du webhook

   Le caBundle doit contenir l’AC qui a émis le certificat serveur du webhook ; l’injecteur d’AC de cert-manager les maintient synchronisés.

   # 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

← Parcourir toute la base de données des erreurs de signature