Échec de la prise de contact tls. Ne contient aucun IP SAN


28

J'essaie de configurer le transitaire logstash, mais j'ai des problèmes avec la création d'un canal sécurisé approprié. Essayer de configurer cela avec deux machines ubuntu (serveur 14.04) exécutées dans virtualbox. Ils sont 100% propres (fichier d'hôtes non touché ou installé d'autres packages autres que java, ngix, elastisearch, etc. requis pour logstash)

Je ne pense pas que ce soit un problème de logstash, mais une mauvaise gestion des certificats ou quelque chose de mal défini sur la machine logstash ubuntu ou le transitaire.

J'ai généré les clés:

sudo openssl req -x509 -batch -nodes -newkey rsa:2048 -keyout private/logstash-forwarder.key -out certs/logstash-forwarder.crt

Ma conf d'entrée sur le serveur logstash:

input {
  lumberjack {
    port => 5000
    type => "logs"
    ssl_certificate => "/etc/pki/tls/certs/logstash-forwarder.crt"
    ssl_key => "/etc/pki/tls/private/logstash-forwarder.key"
  }
}

Les clés ont été copiées sur l' hôte du redirecteur , qui a la configuration suivante.

{
  "network": {
    "servers": [ "192.168.2.107:5000" ],
    "timeout": 15,
    "ssl ca": "/etc/pki/tls/certs/logstash-forwarder.crt"
    "ssl key": "/etc/pki/tls/certs/logstash-forwarder.key"
  },
  "files": [
    {
      "paths": [
        "/var/log/syslog",
        "/var/log/auth.log"
       ],
      "fields": { "type": "syslog" }
    }
   ]
}

Avec le serveur logstash en cours d'exécution, je «sudo service logstash-forwarder start» sur la machine du transitaire, me donnant l'erreur répétée suivante:

Jul  9 05:06:21 ubuntu logstash-forwarder[1374]: 2014/07/09 05:06:21.589762 Connecting to [192.168.2.107]:5000 (192.168.2.107)
Jul  9 05:06:21 ubuntu logstash-forwarder[1374]: 2014/07/09 05:06:21.595105 Failed to tls handshake with 192.168.2.107 x509: cannot validate certificate for 192.168.2.107 because it doesn't contain any IP SANs
Jul  9 05:06:22 ubuntu logstash-forwarder[1374]: 2014/07/09 05:06:22.595971 Connecting to [192.168.2.107]:5000 (192.168.2.107)
Jul  9 05:06:22 ubuntu logstash-forwarder[1374]: 2014/07/09 05:06:22.602024 Failed to tls handshake with 192.168.2.107 x509: cannot validate certificate for 192.168.2.107 because it doesn't contain any IP SANs

Comme je l'ai mentionné plus tôt, je ne pense pas que ce soit un problème de logstash, mais un problème de configuration de certificat / machine. Le problème est que je n'arrive pas à le résoudre. Espérons que quelques esprits intelligents ici pourront m'aider?

Merci

Réponses:


40

... Échec de la prise de contact tls avec 192.168.2.107 x509: impossible de valider le certificat pour 192.168.2.107 car il ne contient aucun SAN IP

SSL a besoin d'une identification de l'homologue, sinon votre connexion pourrait être contre un homme du milieu qui déchiffre + renifle / modifie les données, puis les retransmet cryptées à la cible réelle. L'identification se fait avec des certificats x509 qui doivent être validés par rapport à une autorité de certification de confiance et qui doivent identifier la cible à laquelle vous souhaitez vous connecter.

Habituellement, la cible est donnée en tant que nom d'hôte, ce qui est vérifié par rapport au sujet et aux autres noms de sujet du certificat. Dans ce cas, votre cible est une adresse IP. Pour valider le certificat avec succès, l'IP doit recevoir le certificat dans la section des autres noms de sujet, mais pas en tant qu'entrée DNS (par exemple, nom d'hôte) mais en tant qu'IP.

Donc ce dont vous avez besoin c'est:

  1. Modifier votre /etc/ssl/openssl.cnf sur l'hôte logstash - ajouter subjectAltName = IP:192.168.2.107à la [v3_ca] section.

  2. Recréer le certificat

  3. Copiez le certificat et la clé sur les deux hôtes

PS Envisagez d'ajouter -days 365ou plus à la ligne de commande de création de certificat car la validité du certificat par défaut est de seulement 30 jours et vous ne voulez probablement pas le recréer tous les mois.


Merci pour la réponse rapide. J'ai généré un nouveau certificat sur le serveur. Une inspection rapide me donne les informations suivantes: Émetteur: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = 192.168.2.107 Où 2.107 est l'ip du serveur logstash. Je copie ensuite le crt et la clé sur l'autre machine (transitaire) et l'applique à la configuration. Cela vous semble-t-il correct? Parce que ça
gémit

Veuillez ignorer mon commentaire ci-dessus. J'ai maintenant édité /etc/ssl/openssl.cnf et ajouté subjectAltName = IP: 192.168.2.107 Créé un nouveau certificat avec: 'sudo openssl req -x509 -nodes -newkey rsa: 2048 -keyout private / logstash-forwarder.key - out certs / logstash-forwarder.crt 'Les a copiés et appliqué la configuration et le redémarrage (sur les deux cases). Malheureusement toujours le même problème. Ayant du mal à googler des cas similaires à ce sujet, alors j'espère que vous pourrez me guider vers le bon chemin? :)
connery

1
Vraiment le même problème ou un autre message d'erreur (comme une autorité de certification inconnue ou similaire)? Veuillez poster la partie essentielle du certificat, par exemple à openssl x509 -textpartir du certificat installé sur le serveur. Veuillez également vérifier openssl s_clientque le serveur renvoie le certificat attendu et l'utiliser -CApathavec s_client pour vérifier que la chaîne de confiance peut être vérifiée par rapport à l'autorité de certification configurée.
Steffen Ullrich

J'ai réussi à le faire fonctionner. J'ai mis subjectAltName dans la mauvaise section. Méthode de travail: Fondamentalement, j'ai édité openssl.cnf, dans la section [v3_ca], j'ai ajouté 'subjectAltName = IP: 192.168.2.107'. Produit un nouveau certificat et ajouté au serveur + client. Merci de votre aide! :)
connery

9

Il existe un script pour créer des certificats appropriés pour le bûcheron qui a été mentionné sur un ticket github logstash: la négociation SSL échoue 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

...construit le:

go build lc-tlscert.go

..et courir:

./lc-tlscert 
Specify the Common Name for the certificate. The common name
can be anything, but is usually set to the server's primary
DNS name. Even if you plan to connect via IP address you
should specify the DNS name here.

Common name: you_domain_or_whatever

The next step is to add any additional DNS names and IP
addresses that clients may use to connect to the server. If
you plan to connect to the server via IP address and not DNS
then you must specify those IP addresses here.
When you are finished, just press enter.

DNS or IP address 1: 172.17.42.1 (th ip address to trust)
DNS or IP address 2: 

How long should the certificate be valid for? A year (365
days) is usual but requires the certificate to be regenerated
within a year or the certificate will cease working.

Number of days: 3650
Common name: what_ever
DNS SANs:
    None
IP SANs:
    172.17.42.1

The certificate can now be generated
Press any key to begin generating the self-signed certificate.

Successfully generated certificate
    Certificate: selfsigned.crt
    Private Key: selfsigned.key

Copy and paste the following into your Log Courier
configuration, adjusting paths as necessary:
    "transport": "tls",
    "ssl ca":    "path/to/selfsigned.crt",

Copy and paste the following into your LogStash configuration, 
adjusting paths as necessary:
    ssl_certificate => "path/to/selfsigned.crt",
    ssl_key         => "path/to/selfsigned.key",

1
Cela m'a fait gagner beaucoup de temps aujourd'hui ... mais pour gitlab-runner. Merci!
Matt Messersmith

6

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

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

J'obtiendrais cette erreur:

...
FATA[0000] An error occurred trying to connect: Get https://127.0.0.1:2376/v1.16/version: \
x509: cannot validate certificate for 127.0.0.1 because it doesn't contain any IP SANs 

ce qui me rendait fou. J'avoue, je trébuche dans toutes les choses openssl, donc, tout le monde peut déjà savoir ce que j'ai découvert. L'exemple subjectAltName ici (et partout ailleurs) montre la mise à jour du fichier openssl.cnf. Je ne pouvais pas faire fonctionner ça. J'ai effectué une recherche sur le fichier openssl.cnf, je l'ai copié dans un répertoire local, puis j'y 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 (à partir de l'article du 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, elle 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 le faire fonctionner de cette façon. Quelques lignes plus tard, j'ai remarqué que le certificat «client» utilise un -extfile extfile.cnf. J'ai donc 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 l'a corrigé. Donc, pour quelque raison que ce soit, ma version de openssl ne me permettait pas de modifier le fichier openssl.cnf, mais je pouvais spécifier subjectAltName comme ceci. Fonctionne très bien!

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


Ah-Ha! Merci, je fais la même chose que vous avec docker et je frappe ce problème. Je vais essayer vos suggestions maintenant.
Mark Jones

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.