Falló el apretón de manos. No contiene ninguna SAN IP

28

Estoy tratando de configurar logstash forwarder, pero tengo problemas para hacer un canal seguro adecuado. Intentando configurar esto con dos máquinas ubuntu (servidor 14.04) que se ejecutan en virtualbox. Están 100% limpios (no se tocó el archivo de hosts ni se instaló ningún otro paquete que no sea java, ngix, elastisearch, etc., necesarios para logstash)

No creo que este sea un problema de logstash, pero el manejo incorrecto de los certificados o algo no configurado correctamente en el logstash ubuntu o la máquina de reenvío.

Genere las claves:

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

Mi entrada conf en el servidor 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"
  }
}

Las claves se copiaron al host del reenviador , que tiene la siguiente configuración.

{
  "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 el servidor logstash ejecutándose, 'sudo service logstash-forwarder start' en la máquina del reenviador, dándome el siguiente error repetido:

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

Como mencioné anteriormente, no creo que este sea un problema de logstash, sino un problema de configuración de máquina / certificado. El problema es que parece que no puedo resolverlo. ¿Espero que algunas mentes inteligentes aquí puedan ayudarme?

Gracias

Connery
fuente

Respuestas:

40

... No se pudo establecer el protocolo de enlace con 192.168.2.107 x509: no se puede validar el certificado para 192.168.2.107 porque no contiene ninguna SAN IP

SSL necesita la identificación del igual, de lo contrario, su conexión podría estar en contra de un intermediario que descifra + olfatea / modifica los datos y luego los reenvía nuevamente al objetivo real. La identificación se realiza con certificados x509 que deben validarse con una CA confiable y que necesitan identificar el objetivo al que desea conectarse.

Por lo general, el objetivo se proporciona como un nombre de host y esto se compara con el sujeto y los nombres alternativos del sujeto del certificado. En este caso, su objetivo es una IP. Para validar el certificado con éxito, la IP se debe dar en el certificado dentro de la sección de nombres alternativos del sujeto, pero no como una entrada DNS (por ejemplo, nombre de host) sino como IP.

Entonces, lo que necesitas es:

  1. Edite su /etc/ssl/openssl.cnf en el host logstash - agregue subjectAltName = IP:192.168.2.107en la [v3_ca] sección.

  2. Recrea el certificado

  3. Copie el certificado y la clave en ambos hosts

PD: considere agregar -days 365o más a la línea de comandos de creación de certificados, ya que la validez predeterminada del certificado es de solo 30 días y probablemente no quiera volver a crearla todos los meses.

Steffen Ullrich
fuente
Gracias por la rápida respuesta. Genere un nuevo certificado en el servidor. Una inspección rápida me da lo siguiente: Emisor: C = AU, ST = Algún estado, O = Internet Widgits Pty Ltd, CN = 192.168.2.107 Donde 2.107 es la ip del servidor logstash. Luego copio el crt y la clave a la otra máquina (reenviador) y lo aplico a la configuración. ¿Te parece correcto? Porque todavía está lloriqueando sobre lo mismo ...: P
conecte el
Por favor ignora mi comentario anterior. Ahora edité /etc/ssl/openssl.cnf y agregué subjectAltName = IP: 192.168.2.107. Creé un nuevo certificado con: 'sudo openssl req -x509 -nodes -newkey rsa: 2048 -keyout private / logstash-forwarder.key - out certs / logstash-forwarder.crt 'Los copió y aplicó config y reinicio (en ambos cuadros). Lamentablemente sigue siendo el mismo problema. ¿Le resulta difícil buscar casos similares en esto, así que espero que pueda guiarme por el camino correcto? :)
Connery
1
¿Realmente el mismo problema u otro mensaje de error (como CA desconocido o similar)? Publique la parte esencial del certificado, por ejemplo, openssl x509 -textdel certificado instalado en el servidor. Verifique también openssl s_clientque el servidor devuelva el certificado esperado y utilícelo -CApathcon s_client para verificar que la cadena de confianza se pueda verificar con la CA configurada.
Steffen Ullrich
Me las arreglé para que funcione. Puse subjectAltName en la sección incorrecta. Método de trabajo: Básicamente edité openssl.cnf, en la sección [v3_ca] agregué 'subjectAltName = IP: 192.168.2.107'. Se produjo un nuevo certificado y se agregó al servidor + cliente. ¡Gracias por tu ayuda! :)
Connery
9

Hay un script para crear certs adecuados para el leñador que se mencionó en un ticket logstash github: el protocolo de enlace SSL falla porque faltan IP SAN

Descargar el archivo:

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

...constrúyelo:

go build lc-tlscert.go

..y correr:

./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",
michaelbn
fuente
1
Esto me ahorró mucho tiempo hoy ... aunque para gitlab-runner. ¡Gracias!
Matt Messersmith
6

Tuve un problema real con esto. No estoy usando logstash, simplemente estaba tratando de hacer que las SAN IP funcionen con docker tls. Crearía el certificado como se describe en el artículo de la ventana acoplable en https ( https://docs.docker.com/articles/https/ ), y luego cuando me conectaría desde un cliente de la ventana acoplable:

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

Me daría este error:

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

lo que me estaba volviendo loco. Lo admito, me tropiezo en todas las cosas de manera abierta, por lo tanto, todos pueden saber lo que descubrí. El ejemplo subjectAltName aquí (y en todas partes) muestra la actualización del archivo openssl.cnf. No pude hacer que eso funcione. Hice una localización en el openssl.cnf, lo copié a un directorio local y luego le hice los cambios. Cuando examiné el certificado, no contenía la extensión:

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

El comando que se usa para crear ese certificado está aquí (del artículo de Docker):

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

No puede agregar una línea -config openssl.cnf a este comando, no es válida. Tampoco puede copiar el archivo openssl.cnf en el directorio actual, modificarlo y esperar que funcione de esa manera. Unas líneas más tarde noté que el certificado de 'cliente' usa un archivo -extfile extfile.cnf. Entonces, probé esto:

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

Y eso lo arregló. Entonces, por alguna razón, mi versión de openssl no me permitía modificar el archivo openssl.cnf, pero podría especificar el subjectAltName de esta manera. ¡Funciona genial!

Puede especificar cualquier número de direcciones IP, como IP: 127.0.0.1, IP: 127.0.1.1 (también no localhost).

Greg
fuente
Ah-Ja! Gracias, estoy haciendo lo mismo que usted con Docker y toco este problema. Probaré tus sugerencias ahora.
Mark Jones