Nieudane uzgadnianie tls. Nie zawiera żadnych sieci SAN IP

Próbuję skonfigurować usługę przesyłania dalej logstash, ale mam problemy z utworzeniem odpowiedniego bezpiecznego kanału. Próba skonfigurowania tego na dwóch maszynach Ubuntu (serwer 14.04) działających w virtualbox. Są w 100% czyste (nie dotknęły pliku hosts ani nie zainstalowały żadnych innych pakietów niż wymagana Java, ngix, elastisearch itp. Do logstash)

Nie wierzę, że jest to problem z logstash, ale niewłaściwa obsługa certyfikatów lub coś niepoprawnie ustawione na Ubuntu logstash lub maszynie do przesyłania dalej.

Wygenerowałem klucze:

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

Moje wejście conf na serwerze 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"
  }
}

Klucze zostały skopiowane do hosta przekazującego , który ma następującą konfigurację.

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

Po uruchomieniu serwera logstash uruchamiam „sudo service logstash-forwarder start” na maszynie przekazującej, co powoduje następujący powtarzający się błąd:

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

Jak wspomniałem wcześniej, nie sądzę, że jest to problem związany z logstash, ale problem z konfiguracją certyfikatu / komputera. Problem polega na tym, że nie mogę tego rozwiązać. Mam nadzieję, że niektóre sprytne umysły mogą mi pomóc?

Dzięki

... Nie udało się nawiązać połączenia tls z 192.168.2.107 x509: nie można zweryfikować certyfikatu dla 192.168.2.107, ponieważ nie zawiera on żadnych SAN-ów IP

SSL wymaga identyfikacji peera, w przeciwnym razie twoje połączenie może być skierowane przeciwko man-in-the-middle, który odszyfrowuje + wącha / modyfikuje dane, a następnie przesyła je ponownie zaszyfrowane do prawdziwego celu. Identyfikacji dokonuje się za pomocą certyfikatów x509, które należy zweryfikować względem zaufanego urzędu certyfikacji i które muszą zidentyfikować cel, z którym chcesz się połączyć.

Zazwyczaj cel jest podawany jako nazwa hosta i jest on sprawdzany w stosunku do podmiotu i alternatywnych nazw podmiotu certyfikatu. W tym przypadku twoim celem jest adres IP. Aby pomyślnie zweryfikować certyfikat, adres IP musi zostać podany w certyfikacie w sekcji alternatywnych nazw tematów, ale nie jako wpis DNS (np. Nazwa hosta), ale zamiast tego jako IP.

Musisz więc:

1. Edytuj swój /etc/ssl/openssl.cnf na hoście logstash - dodaj subjectAltName = IP:192.168.2.107w [v3_ca] sekcji.

2. Utwórz ponownie certyfikat

3. Skopiuj certyfikat i klucz do obu hostów

PS Rozważ dodanie -days 365lub więcej do wiersza polecenia tworzenia certyfikatu, ponieważ domyślny okres ważności certyfikatu to tylko 30 dni i prawdopodobnie nie chcesz go odtwarzać co miesiąc.

Istnieje skrypt do tworzenia odpowiednich certyfikatów dla drwala, który został wspomniany na bilecie github logstash: Uzgadnianie SSL kończy się niepowodzeniem, ponieważ brakuje SAN IP

Pobierz plik:

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

...Zbuduj to:

go build lc-tlscert.go

..i biegnij:

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

Miałem z tym prawdziwy problem. Nie używam logstash, po prostu próbowałem zmusić IP SAN do pracy z tl dokerem. Utworzyłbym certyfikat zgodnie z opisem w artykule dokera na https ( https://docs.docker.com/articles/https/ ), a następnie, gdy łączyłem się z klienta dokera:

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

Otrzymałbym ten błąd:

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

co doprowadzało mnie do szału. Przyznaję, potykam się we wszystkich rzeczach, więc każdy może już wiedzieć, co odkryłem. Przykład subjectAltName tutaj (i gdziekolwiek indziej) pokazuje aktualizację pliku openssl.cnf. Nie mogłem tego uruchomić. Zrobiłem lokalizację na openssl.cnf, skopiowałem ją do lokalnego katalogu, a następnie wprowadziłem zmiany. Kiedy sprawdziłem certyfikat, nie zawierał on rozszerzenia:

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

Komenda używana do utworzenia tego certyfikatu znajduje się tutaj (z artykułu dokera):

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

Nie można dodać wiersza -config openssl.cnf do tego polecenia, jest ono niepoprawne. Nie możesz również skopiować pliku openssl.cnf do bieżącego katalogu, zmodyfikować go i mieć nadzieję, że zadziała w ten sposób. Kilka wierszy później zauważyłem, że „klient” cert używa pliku-tekstowego extfile.cnf. Próbowałem więc:

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

i to naprawiło. Tak więc, z jakiegokolwiek powodu moja wersja openssl nie pozwalała mi modyfikować pliku openssl.cnf, ale mogłem określić podmiotAltName w ten sposób. Działa świetnie!

Możesz podać dowolną liczbę adresów IP, takich jak IP: 127.0.0.1, IP: 127.0.1.1 (również nie lokalny host).

Szybka poprawka znajduje się powyżej w rozwiązaniu @Steffen Ullrich.

Jest także problem / dyskusja na ten temat w github projektu logstash-forwarder . Zobacz (wkrótce, ponieważ obecnie trwają prace nad nim), aby uzyskać łatwiejsze rozwiązanie.