x509: certificate is valid for example.com, not api.example.com

Les deux noms sont propres à chaque échec : d’abord les noms que couvre le certificat, puis le nom demandé par votre client.

Go crypto/x509 — HostnameError from VerifyHostname / TLS dials

Ce que cela signifie

La connexion TLS est allée assez loin pour lire le certificat, mais aucun de ses noms alternatifs du sujet (Subject Alternative Names, SAN) ne correspond au nom d’hôte auquel le client s’est connecté. L’erreur indique les deux côtés, si bien que l’écart saute aux yeux : le certificat couvre X, vous avez demandé Y. Notez que la vérification moderne n’utilise que les SAN ; l’ancien champ du nom commun (Common Name) est ignoré.

Pourquoi cela se produit

• Il manque le nom utilisé dans la liste des SAN

  fréquente

  Un certificat émis pour example.com ne couvre pas api.example.com (et un wildcard *.example.com ne couvre qu’un seul niveau : ni example.com lui-même, ni a.b.example.com). Les nouveaux sous-domaines nécessitent des certificats réémis.

• Connexion à un alias interne

  fréquente

  Si vous vous connectez à un nom de service docker-compose ou à un autre alias interne, le serveur présente le certificat de l’identité qu’il s’attribue : les SAN contiennent des noms DNS publics, et non votre alias, donc la correspondance échoue. Une connexion à une adresse IP brute échoue plutôt avec un message voisin : « x509: cannot validate certificate for 10.0.0.5 because it doesn't contain any IP SANs ».

• Le serveur sert un mauvais certificat ou son certificat par défaut (SNI)

  occasionnelle

  Les ingress multi-locataires choisissent le certificat selon le SNI. Lorsqu’un client omet ServerName, ou qu’un ingress n’a pas de règle pour l’hôte, c’est le certificat par défaut qui est servi, souvent un certificat de substitution comme « Kubernetes Ingress Controller Fake Certificate ».

Comment corriger l’erreur

1. 1.

   Réémettre le certificat avec tous les noms réellement utilisés

   Ajoutez tous les noms d’hôte comme SAN lors de l’émission ; examinez la liste actuelle des SAN pour voir ce qui est couvert aujourd’hui.

   echo | openssl s_client -connect host:443 -servername api.example.com 2>/dev/null \
     | openssl x509 -noout -ext subjectAltName
   # request with SANs:
   openssl req -new -key key.pem -out req.csr \
     -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:api.example.com"

2. 2.

   Se connecter par le nom, ou définir ServerName explicitement

   Lorsque l’adresse réseau doit différer du nom du certificat (VIP, redirection de port, sidecar), indiquez à TLS l’identité que vous attendez, pour que la vérification reste effective.

   conn, err := tls.Dial("tcp", "10.0.0.5:443", &tls.Config{
       ServerName: "api.example.com",   // matched against SANs, sent as SNI
   })

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