Échec de la poignée de main tls. Ne contient aucune SAN IP

Il existe un script pour créer des certificats appropriés pour les bûcherons qui a été mentionné sur un ticket GitHub de logstash : L'échec de l'authentification SSL car les SAN IP sont manquants

Téléchargez le fichier :

curl -O https://raw.githubusercontent.com/driskell/log-courier/1.x/src/lc-tlscert/lc-tlscert.go

...compilez-le:

go build lc-tlscert.go

..et exécutez :

./lc-tlscert 
Indiquez le Nom Commun pour le certificat. Le nom commun
peut être n'importe quoi, mais est généralement défini sur le nom DNS principal du serveur. Même si vous prévoyez de vous connecter via une adresse IP, vous devriez spécifier le nom DNS ici.

Nom commun: votre_domaine_ou_autre

La prochaine étape consiste à ajouter des noms DNS supplémentaires et des adresses IP
 que les clients peuvent utiliser pour se connecter au serveur. Si
vous prévoyez de vous connecter au serveur via une adresse IP et non un DNS
vous devez spécifier ces adresses IP ici.
Une fois que vous avez fini, appuyez simplement sur Entrée.

DNS ou adresse IP 1: 172.17.42.1 (adresse IP à faire confiance)
DNS ou adresse IP 2: 

Combien de temps le certificat doit-il être valide? Un an (365 jours)
est habituel mais nécessite que le certificat soit régénéré
dans un an sinon le certificat cessera de fonctionner.

Nombre de jours: 3650
Nom commun: quel_que_soit
SAN DNS:
    Aucun
SAN IP:
    172.17.42.1

Le certificat peut maintenant être généré
Appuyez sur n'importe quelle touche pour commencer la génération du certificat auto-signé.

Certificat généré avec succès
    Certificat: selfsigned.crt
    Clé privée: selfsigned.key

Copiez et collez ce qui suit dans votre configuration Log Courier
en ajustant les chemins si nécessaire:
    "transport": "tls",
    "ssl ca":    "chemin/vers/auto-signé.crt",

Copiez et collez ce qui suit dans votre configuration LogStash, 
en ajustant les chemins si nécessaire:
    ssl_certificate => "chemin/vers/auto-signé.crt",
    ssl_key         => "chemin/vers/auto-signé.key",

J'ai eu un vrai problème avec ça. Je n'utilise pas logstash, j'essayais simplement de faire fonctionner les IP SAN avec tls docker. Je créerais le certificat comme décrit dans l'article docker sur https (https://docs.docker.com/articles/https/), puis quand je me connectais à partir d'un client docker :

docker --tlsverify  -H tcp://127.0.0.1:2376 version

Je recevais cette erreur :

...
FATA[0000] Une erreur s'est produite en essayant de se connecter : Obtenir https://127.0.0.1:2376/v1.16/version : \
x509: ne peut pas valider le certificat pour 127.0.0.1 car il ne contient pas d'IP SAN 

ce qui me rendait fou. J'avoue, je tâtonne dans tout ce qui concerne openssl, donc, tout le monde pourrait déjà savoir ce que j'ai découvert. L'exemple de subjectAltName ici (et partout ailleurs) montre la mise à jour du fichier openssl.cnf. Je n'ai pas réussi à le faire fonctionner. J'ai fait un locate sur le openssl.cnf, copié dans un répertoire local, puis j'ai apporté les modifications. Lorsque j'ai examiné le certificat, il ne contenait pas l'extension :

openssl x509 -noout -text -in server-cert.pem

La commande utilisée pour créer ce certificat est ici (de l'article docker) :

openssl x509 -req -days 365 -in server.csr -CA ca.pem -CAkey ca-key.pem \
    -CAcreateserial -out server-cert.pem

Vous ne pouvez pas ajouter une ligne -config openssl.cnf à cette commande, ce n'est pas valide. Vous ne pouvez pas non plus copier le fichier openssl.cnf dans le répertoire actuel, le modifier et espérer que cela fonctionne de cette façon. Quelques lignes plus loin, j'ai remarqué que le certificat 'client' utilise un -extfile extfile.cnf. Donc, j'ai essayé ceci :

echo subjectAltName = IP:127.0.0.1 > extfile.cnf
openssl x509 -req -days 365 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial \
   -out server-cert.pem -extfile extfile.cnf

et cela a résolu le problème. Donc, pour une raison quelconque, ma version d'openssl ne me permettait pas de modifier le fichier openssl.cnf, mais je pouvais spécifier le subjectAltName de cette façon. Ça marche super !

Vous pouvez spécifier n'importe quel nombre d'adresses IP, comme IP:127.0.0.1,IP:127.0.1.1 (non localhost également).

Dès OpenSSL 1.1.1, fournir subjectAltName directement en ligne de commande devient beaucoup plus facile, avec l'introduction du drapeau -addext à openssl req

Exemple:

export HOST="mon.hote"
export IP="127.0.0.1"
openssl req -newkey rsa:4096 -nodes -keyout ${HOST}.key -x509 -days 365 -out ${HOST}.crt -addext 'subjectAltName = IP:${IP}' -subj '/C=US/ST=CA/L=SanFrancisco/O=MyCompany/OU=RND/CN=${HOST}/'

Inspiré par lien

Veuillez consulter la solution de @Steffen Ullrich ci-dessus pour la correction rapide.

Il y a également un problème en discussion concernant cela dans le projet logstash-forwarder sur Github. Consultez-le (bientôt, car le travail est actuellement en cours) pour une solution plus facile.