Frage Fehlgeschlagen tls Händedruck. Enthält keine IP-SANs


Ich versuche, Logstash Forwarder einzurichten, aber ich habe Probleme mit dem Erstellen eines sicheren Kanals. Versuchen Sie dies mit zwei ubuntu (Server 14.04) Maschinen zu konfigurieren, die in virtualbox laufen. Sie sind 100% sauber (nicht berührte Hosts-Datei oder installiert andere Pakete als die erforderlichen Java, ngix, elastisearch, etc, für logstash)

Ich glaube nicht, dass dies ein logstash-Problem ist, sondern eine unsachgemäße Behandlung von Zertifikaten oder etwas, das auf dem Logstash-Ubuntu- oder Forwarder-Rechner nicht korrekt eingestellt ist.

Ich habe die Schlüssel erzeugt:

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

Meine Eingabe conf auf 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"
  }
}

Schlüssel wurden kopiert Forwarder-Host, die die folgende Konfiguration hat.

{
  "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 läuft, I 'sudo-Dienst logstash-Forwarder Start' auf dem Forwarder-Maschine, geben Sie mir den folgenden wiederholten Fehler:

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 ich bereits erwähnt habe, glaube ich nicht, dass dies ein logstash-Problem ist, sondern ein Problem mit der Zertifikats- / Computerkonfiguration. Das Problem ist, ich kann es anscheinend nicht lösen. Hoffentlich können mir hier einige kluge Köpfe helfen?

Vielen Dank


22
2017-07-09 04:23


Ursprung




Antworten:


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

SSL benötigt eine Identifizierung des Peers, andernfalls könnte Ihre Verbindung gegen einen Man-in-the-Middle gerichtet sein, der die Daten entschlüsselt + schnüffelt / modifiziert und sie dann wieder verschlüsselt an das reale Ziel weiterleitet. Die Identifizierung erfolgt mit x509-Zertifikaten, die für eine vertrauenswürdige Zertifizierungsstelle validiert werden müssen und die das Ziel identifizieren müssen, mit dem Sie eine Verbindung herstellen möchten.

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

Also was du brauchst ist:

  1. Bearbeiten Sie Ihre /etc/ssl/openssl.cnf  auf dem logstash-Host - hinzufügen subjectAltName = IP:192.168.2.107 im [v3_ca]  Sektion.

  2. Erstellen Sie das Zertifikat neu

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

PS Erwägen Sie das Hinzufügen -days 365 oder mehr auf die Befehlszeile zum Erstellen von Zertifikaten, da die Standardzertifikatgültigkeit nur 30 Tage beträgt und Sie diese wahrscheinlich nicht jeden Monat neu erstellen möchten.


30
2017-07-09 04:33



Danke für die schnelle Antwort. Ich habe ein neues Zertifikat auf dem Server erstellt. Eine schnelle Inspektion gibt mir folgendes: Herausgeber: C = AU, ST = Irgendein Staat, O = Internet Widgits Pty Ltd, CN = 192.168.2.107 Wo 2.107 ist der Logstash Server IP. Ich kopiere dann den crt und den Schlüssel auf den anderen Rechner (Weiterleitung) und wende ihn an die Konfiguration an. Klingt das für Sie richtig? Weil es immer noch nach dem gleichen Ding jammert ...: P - connery
Bitte ignoriere meinen obigen Kommentar. Ich habe jetzt /etc/ssl/openssl.cnf bearbeitet und subjectAltName = IP: 192.168.2.107 hinzugefügt Erstellt ein neues Zertifikat mit: 'sudo openssl req -x509 -nodes -neuschlüssel rsa: 2048 -keyout private / logstash-forwarder.key - out certs / logstash-forwarder.crt 'Kopierte sie und setzte Config und Neustart (auf beiden Boxen). Leider immer noch das gleiche Problem. Ich habe Schwierigkeiten, ähnliche Fälle zu googeln, und hoffentlich können Sie mich auf den richtigen Weg führen? :) - connery
Wirklich das gleiche Problem oder eine andere Fehlermeldung (wie unbekannte CA oder ähnliches)? Bitte veröffentlichen Sie den wesentlichen Teil des Zertifikats, z. openssl x509 -text von dem auf dem Server installierten Zertifikat. Bitte überprüfen Sie auch mit openssl s_client dass der Server das erwartete Zertifikat zurückgibt und verwendet -CApath mit s_client, um zu überprüfen, ob die Vertrauenskette mit der konfigurierten CA verifiziert werden kann. - Steffen Ullrich
Ich habe es geschafft, es zur Arbeit zu bringen. Ich habe subjectAltName in den falschen Abschnitt eingefügt. Arbeitsmethode: Im Grunde habe ich openssl.cnf bearbeitet, im Abschnitt [v3_ca] habe ich 'subjectAltName = IP: 192.168.2.107' hinzugefügt. Neues Zertifikat erstellt und zu Server + Client hinzugefügt. Danke für Ihre Hilfe! :) - connery


Es gibt ein Skript zum Erstellen der richtigen Zertifikate für Holzfäller, das auf einem Logstash-GitHub-Ticket erwähnt wurde: Der 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",

7
2017-08-23 12:43





Ich hatte ein echtes Problem damit. Ich benutze nicht logstash, ich habe einfach versucht, IP-SANs mit docker tls zu arbeiten. Ich würde das Zertifikat erstellen, wie im Docker-Artikel auf https beschrieben (https://docs.docker.com/articles/https/), wenn ich von einem Docker-Client aus eine Verbindung 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 

was mich verrückt machte. Ich gebe zu, ich stolpere in allen Dingen offen herum, also weiß vielleicht jeder schon, was ich entdeckt habe. Das Beispiel subjectAltName hier (und wo auch immer) zeigt das Aktualisieren der Datei openssl.cnf. Ich konnte das nicht zur Arbeit bringen. Ich habe ein locate auf der openssl.cnf gemacht, es in ein lokales Verzeichnis kopiert und dann die Änderungen daran vorgenommen. Als ich das Zertifikat untersuchte, enthielt es nicht die Erweiterung:

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

Der Befehl, der zum Erstellen dieses Zertifikats verwendet wird, ist 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-Zeile openssl.cnf hinzufügen, sie ist nicht gültig. Sie können die Datei openssl.cnf auch nicht in das aktuelle Verzeichnis kopieren, sie ändern und hoffen, dass sie so funktioniert. Ein paar Zeilen später bemerkte ich, dass das 'client' cert eine -extfile extfile.cnf benutzt. 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 openssl.cnf-Datei zu ändern, aber ich konnte den subjectAltName wie folgt 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).


6
2018-02-11 19:05



Ah-Ha! Danke, ich mache dasselbe wie du mit Docker und triff dieses Problem. Ich werde jetzt Ihre Vorschläge versuchen. - Mark Jones


Bitte beachten Sie die Lösung von @Steffen Ullrich für die schnelle Lösung.

Es gibt auch ein Problem / eine Diskussion darüber im Github des Logstash-Forwarder-Projekts. Sehen Sie es (bald, wie zur Zeit arbeiten es ist in Arbeit) für eine einfachere Lösung.


0
2017-07-17 08:54