Stretta di mano tls fallita. Non contiene alcuna SAN IP


28

Sto cercando di impostare il forwarder del logstash, ma ho problemi con la creazione di un canale sicuro adeguato. Sto provando a configurarlo con due macchine ubuntu (server 14.04) in esecuzione in virtualbox. Sono puliti al 100% (file host non toccato o installato qualsiasi altro pacchetto diverso da java, ngix, elastisearch, ecc. Richiesti per logstash)

Non credo che questo sia un problema di logstash, ma una gestione impropria dei certificati o qualcosa di non impostato correttamente sul Ubuntu logstash o sul server di inoltro.

Ho generato le chiavi:

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

Il mio input conf sul server 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"
  }
}

Le chiavi sono state copiate nell'host di inoltro , che presenta la seguente configurazione.

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

Con il server logstash in esecuzione, 'sudo service logstash-forwarder start' sulla macchina forwarder, dandomi il seguente errore ripetuto:

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

Come accennato in precedenza, non credo che questo sia un problema di logstash, ma un problema di configurazione certificato / macchina. Il problema è che non riesco a risolverlo. Spero che alcune menti intelligenti qui possano aiutarmi?

Grazie

Risposte:


40

... Impossibile eseguire l'handshake di tls con 192.168.2.107 x509: impossibile convalidare il certificato per 192.168.2.107 perché non contiene SAN IP

SSL richiede l'identificazione del peer, altrimenti la tua connessione potrebbe essere contro un man-in-the-middle che decodifica + annusa / modifica i dati e quindi li inoltra nuovamente crittografati al target reale. L'identificazione viene eseguita con certificati x509 che devono essere convalidati rispetto a un'autorità di certificazione attendibile e che devono identificare la destinazione a cui si desidera connettersi.

Di solito il target viene assegnato come nome host e questo viene verificato rispetto al soggetto e ai nomi alternativi soggetto del certificato. In questo caso il tuo obiettivo è un IP. Per convalidare correttamente il certificato, l'IP deve essere fornito nel certificato all'interno della sezione nomi alternativi soggetto, ma non come voce DNS (ad es. Nome host) ma come IP.

Quindi quello che devi fare è:

  1. Modifica il tuo /etc/ssl/openssl.cnf host sul logstash - aggiungi subjectAltName = IP:192.168.2.107nella [v3_ca] sezione.

  2. Ricrea il certificato

  3. Copia il certificato e la chiave su entrambi gli host

PS Considera di aggiungere -days 365o più alla riga di comando per la creazione del certificato poiché la validità predefinita del certificato è di soli 30 giorni e probabilmente non vorrai ricrearla ogni mese.


Grazie per la risposta rapida. Ho generato un nuovo certificato sul server. Un rapido controllo mi dà quanto segue: Emittente: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = 192.168.2.107 Dove 2.107 è l'IP del server logstash. Quindi copio crt e key sull'altra macchina (forwarder) e lo applico alla configurazione. Ti sembra corretto? Perché è ancora lamentoso per la stessa cosa ...: P
connery

Si prega di ignorare il mio commento sopra. Ora ho modificato /etc/ssl/openssl.cnf e aggiunto subjectAltName = IP: 192.168.2.107 Creato un nuovo certificato con: 'sudo openssl req -x509 -nodes -newkey rsa: 2048 -keyout private / logstash-forwarder.key - out certs / logstash-forwarder.crt 'Copiati e applicati config e riavvio (su entrambe le caselle). Purtroppo è sempre lo stesso problema. Hai difficoltà a cercare su Google casi simili su questo, quindi spero che tu sia in grado di guidarmi sulla strada giusta? :)
connery

1
Davvero lo stesso problema o un altro messaggio di errore (come CA sconosciuta o simile)? Si prega di inviare la parte essenziale del certificato, ad es. openssl x509 -textDal certificato installato sul server. Verificare inoltre openssl s_clientche il server restituisca il certificato previsto e utilizzarlo -CApathcon s_client per verificare che la catena di fiducia possa essere verificata rispetto alla CA configurata.
Steffen Ullrich,

Sono riuscito a farlo funzionare. Ho inserito subjectAltName nella sezione sbagliata. Metodo di lavoro: sostanzialmente ho modificato openssl.cnf, nella sezione [v3_ca] ho aggiunto 'subjectAltName = IP: 192.168.2.107'. Prodotto nuovo certificato e aggiunto al server + client. Grazie per l'aiuto! :)
connery

9

Esiste uno script per la creazione di certificati appropriati per boscaiolo che è stato menzionato su un ticket github logstash: l'handshake SSL non riesce perché mancano le SAN IP

Scarica il file:

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

...costruiscilo:

go build lc-tlscert.go

..e corri:

./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
Questo mi ha fatto risparmiare un sacco di tempo oggi ... anche se per Gitlab-Runner. Grazie!
Matt Messersmith,

6

Ho avuto un vero problema con questo. Non sto usando logstash, stavo semplicemente cercando di far funzionare IP SAN con docker tls. Vorrei creare il certificato come descritto nell'articolo docker su https ( https://docs.docker.com/articles/https/ ), quindi quando mi collegherei da un client docker:

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

Vorrei ottenere questo errore:

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

che mi stava facendo impazzire. Lo ammetto, mi imbatto in tutto ciò che si apre, quindi tutti potrebbero già sapere cosa ho scoperto. L'esempio subjectAltName qui (e in qualsiasi altro luogo) mostra l'aggiornamento del file openssl.cnf. Non riuscivo a farlo funzionare. Ho individuato il file openssl.cnf, l'ho copiato in una directory locale, quindi ho apportato le modifiche. Quando ho esaminato il certificato non conteneva l'estensione:

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

Il comando utilizzato per creare quel certificato è qui (dall'articolo della finestra mobile):

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

Non è possibile aggiungere una riga -config openssl.cnf a questo comando, non è valido. Né è possibile copiare il file openssl.cnf nella directory corrente, modificarlo e sperare di farlo funzionare in quel modo. Alcune righe più tardi ho notato che il certificato 'client' usa un extext file extfile.cnf. Quindi, ho provato questo:

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

e questo l'ha risolto. Quindi, per qualunque motivo la mia versione di openssl non mi permetteva di modificare il file openssl.cnf, ma potevo specificare subjectAltName in questo modo. Funziona alla grande!

Puoi specificare qualsiasi numero di indirizzi IP, come IP: 127.0.0.1, IP: 127.0.1.1 (anche non localhost).


Ah-ha! Grazie, sto facendo la stessa cosa che hai con la finestra mobile e ho risolto questo problema. Proverò i tuoi suggerimenti ora.
Mark Jones,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.