Handshake fehlgeschlagen. Enthält keine IP-SANs

Ich versuche, die Logstash-Weiterleitung einzurichten, habe jedoch Probleme, einen ordnungsgemäßen sicheren Kanal einzurichten. Der Versuch, dies mit zwei Ubuntu-Computern (Server 14.04) zu konfigurieren, die in virtualbox ausgeführt werden. Sie sind zu 100% sauber (keine Hosts-Datei berührt oder andere Pakete als die erforderlichen Java-, NGIX-, Elastisearch- usw. für Logstash installiert).

Ich glaube nicht, dass dies ein Logstash-Problem ist, aber eine unsachgemäße Behandlung von Zertifikaten oder etwas, das weder auf dem Logstash-Ubuntu- noch auf dem Weiterleitungscomputer korrekt eingestellt ist.

Ich habe die Schlüssel generiert:

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

Meine Eingabe auf dem Logstash-Server:

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

Die Schlüssel wurden auf den Weiterleitungshost kopiert , der die folgende Konfiguration aufweist.

{
  "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" }
    }
   ]
}

Wenn der Logstash-Server ausgeführt wird, wird auf dem Weiterleitungscomputer "sudo service logstash-forwarder start" ausgeführt , und es wird der folgende wiederholte Fehler angezeigt :

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

Wie bereits erwähnt, handelt es sich meines Erachtens nicht um ein Logstash-Problem, sondern um ein Problem mit der Zertifikat- / Computerkonfiguration. Das Problem ist, ich kann es scheinbar nicht lösen. Hoffentlich können einige kluge Köpfe hier mir helfen?

Vielen Dank

... Handshake mit 192.168.2.107 x509 fehlgeschlagen: Zertifikat für 192.168.2.107 kann nicht validiert werden, da es keine IP-SANs enthält

SSL muss den Peer identifizieren, andernfalls könnte Ihre Verbindung gegen einen Man-in-the-Middle-Server gerichtet sein, der die Daten entschlüsselt, aufspürt und modifiziert und sie dann erneut verschlüsselt an das eigentliche Ziel weiterleitet. Die Identifizierung erfolgt mit x509-Zertifikaten, die gegen eine vertrauenswürdige Zertifizierungsstelle validiert werden müssen und die das Ziel identifizieren müssen, zu dem Sie eine Verbindung herstellen möchten.

Normalerweise wird das Ziel als Hostname angegeben und dies wird mit dem Betreff und den alternativen Betreffnamen des Zertifikats verglichen. In diesem Fall ist Ihr Ziel eine IP. Um das Zertifikat erfolgreich zu validieren, muss die IP im Zertifikat im Abschnitt für alternative Namen des Betreffs angegeben werden, jedoch nicht als DNS-Eintrag (z. B. Hostname), sondern als IP.

Was Sie also brauchen, ist:

1. Bearbeiten Sie Ihre /etc/ssl/openssl.cnf auf dem Logstash-Host - Hinzufügen subjectAltName = IP:192.168.2.107in [v3_ca] Abschnitt.

2. Erstellen Sie das Zertifikat neu

3. Kopieren Sie das Zertifikat und den Schlüssel auf beide Hosts

PS: Erwägen Sie -days 365, der Befehlszeile zum Erstellen von Zertifikaten mehr oder mehr Elemente hinzuzufügen, da die Standardgültigkeit des Zertifikats nur 30 Tage beträgt und Sie es wahrscheinlich nicht jeden Monat neu erstellen möchten.

Es gibt ein Skript zum Erstellen der richtigen Zertifikate für Holzfäller, das auf einem Logstash-Github-Ticket erwähnt wurde: SSL-Handshake schlägt fehl, weil IP-SANs fehlen

Laden Sie die Datei herunter:

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

...baue es:

go build lc-tlscert.go

..und Renn:

./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",

Ich hatte ein echtes Problem damit. Ich verwende kein Logstash. Ich habe lediglich versucht, IP-SANs für die Arbeit mit Docker-TLs zu aktivieren. Ich würde das Zertifikat wie im Docker-Artikel unter https ( https://docs.docker.com/articles/https/ ) beschrieben erstellen und dann, wenn ich eine Verbindung von einem Docker-Client aus herstellen würde:

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

Ich würde diesen Fehler bekommen:

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

Das hat mich verrückt gemacht. Ich gebe zu, ich stolpere in allen Dingen herum, also könnte jeder schon wissen, was ich entdeckt habe. Das subjectAltName-Beispiel hier (und an allen anderen Stellen) zeigt, wie die openssl.cnf-Datei aktualisiert wird. Ich konnte das nicht zum Laufen bringen. Ich habe eine Suche in der Datei openssl.cnf durchgeführt, sie in ein lokales Verzeichnis kopiert und dann die Änderungen vorgenommen. Als ich das Zertifikat untersuchte, enthielt es nicht die Erweiterung:

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

Der Befehl zum Erstellen dieses Zertifikats lautet hier (aus dem Docker-Artikel):

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

Sie können diesem Befehl keine -config openssl.cnf-Zeile hinzufügen, sie ist ungültig. Sie können die Datei openssl.cnf auch nicht in das aktuelle Verzeichnis kopieren, ändern und hoffen, dass sie so funktioniert. Ein paar Zeilen später bemerkte ich, dass das 'Client'-Zertifikat eine -extfile extfile.cnf verwendet. Also habe ich Folgendes versucht:

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

und das hat es behoben. Aus irgendeinem Grund erlaubte mir meine Version von openssl nicht, die Datei openssl.cnf zu ändern, aber ich konnte den subjectAltName so angeben. Funktioniert super!

Sie können eine beliebige Anzahl von IP-Adressen angeben, z. B. IP: 127.0.0.1, IP: 127.0.1.1 (auch nicht localhost).

Weitere Informationen zur schnellen Fehlerbehebung finden Sie oben in der Lösung von @Steffen Ullrich.

Es gibt auch ein Problem / eine Diskussion darüber im Github des Logstash-Forwarder-Projekts . Sehen Sie es sich an (in Kürze wird daran gearbeitet), um eine einfachere Lösung zu finden.