web-dev-qa-db-fra.com

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

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 réglé 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 dans 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

ubuntusslssl-certificatetlslogstash
31
connery

... É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 pas de 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 et cela 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. Modifiez votre /etc/ssl/openssl.cnfsur l'hôte logstash - ajoutez subjectAltName = IP:192.168.2.107 dans [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 365 ou 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 voudrez probablement pas le recréer tous les mois.

41
Steffen Ullrich

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 prise de contact 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",
11
michaelbn

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

7
Greg

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

Il y a aussi n problème/une discussion à ce sujet dans le github du projet logstash-forwarder . Voyez-le (bientôt, car les travaux sont en cours) pour une solution plus simple.

0
Greg Dubicki