Falha no aperto de mão tls. Não contém quaisquer SANs IP

... Falha ao tls handshake com 192.168.2.107 x509: não é possível validar o certificado para 192.168.2.107 porque não contém nenhuma SAN IP

O SSL precisa de identificação do peer, caso contrário, sua conexão pode ser contra um intermediário que descriptografa + fareja/modifica os dados e os encaminha criptografados novamente para o destino real. A identificação é feita com certificados x509 que precisam ser validados em relação a uma CA confiável e que precisam identificar o destino ao qual você deseja se conectar.

Normalmente, o destino é fornecido como um nome de host e isso é verificado em relação aos nomes alternativos de assunto e assunto do certificado. Neste caso, seu alvo é um IP. Para validar o certificado com sucesso, o IP deve ser fornecido no certificado dentro da seção de nomes alternativos do assunto, mas não como uma entrada DNS (por exemplo, nome do host), mas como IP.

Então o que você precisa é:

1. Edite seu /etc/ssl/openssl.cnf no host do logstash - adicione subjectAltName = IP:192.168.2.107na [v3_ca] seção.

2. Recriar o certificado

3. Copie o certificado e a chave para ambos os hosts

PS Considere adicionar -days 365ou mais à linha de comando de criação do certificado, pois a validade padrão do certificado é de apenas 30 dias e você provavelmente não deseja recriá-lo todos os meses.

Existe um script para criar certificados adequados para lenhador que foi mencionado em um tíquete do github do logstash: o handshake SSL falha porque não há IP SANs

Baixe o arquivo:

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

...construa:

go build lc-tlscert.go

..e corra:

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

Eu tive um problema real com isso. Não estou usando o logstash, estava simplesmente tentando fazer com que as SANs IP funcionassem com o docker tls. Eu criaria o certificado conforme descrito no artigo do docker em https ( https://docs.docker.com/articles/https/ ), então quando eu me conectaria de um cliente do docker:

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

Eu receberia este erro:

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

que estava me deixando louco. Eu admito, eu tropeço em todas as coisas do openssl, então, todo mundo já deve saber o que eu descobri. O exemplo subjectAltName aqui (e em todos os outros lugares) mostra a atualização do arquivo openssl.cnf. Não consegui fazer isso funcionar. Eu localizei no openssl.cnf, copiei-o para um diretório local e fiz as alterações nele. Quando examinei o certificado, ele não continha a extensão:

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

O comando que está sendo usado para criar esse certificado está aqui (do artigo docker):

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

Você não pode adicionar uma linha -config openssl.cnf a este comando, ela não é válida. Você também não pode copiar o arquivo openssl.cnf para o diretório atual, modificá-lo e esperar que funcione dessa maneira. Algumas linhas depois, notei que o certificado 'client' usa um -extfile extfile.cnf. Então, eu tentei isso:

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 isso resolveu. Então, por alguma razão, minha versão do openssl não estava me permitindo modificar o arquivo openssl.cnf, mas eu poderia especificar o subjectAltName assim. Funciona bem!

Você pode especificar qualquer número de endereços IP, como IP:127.0.0.1,IP:127.0.1.1 (não localhost também).

A partir do OpenSSL 1.1.1, fornecer subjectAltName diretamente na linha de comando ficou muito mais fácil, com a introdução do -addextsinalizador paraopenssl req

Exemplo:

export HOST="my.host"
export IP="127.0.0.1"
openssl req -newkey rsa:4096 -nodes -keyout ${HOST}.key -x509 -days 365 -out ${HOST}.crt -addext 'subjectAltName = IP:${IP}' -subj '/C=US/ST=CA/L=SanFrancisco/O=MyCompany/OU=RND/CN=${HOST}/'

Inspirado no link

Por favor, veja a solução de @Steffen Ullrich acima para a solução rápida.

Há também um problema/uma discussão sobre isso no github do projeto logstash-forwarder . Veja-o (em breve, pois atualmente o trabalho está em andamento) para uma solução mais fácil.