não pode validar certificado - não contém nenhum IP SAN

1

Atualmente, estou no processo de instalação da pilha ELK (ElastricSearch, LogStash & Kibana).

O endereço IP do meu servidor ELK é 172.29.225.32 .

A configuração da pesquisa elástica é:

# ---------------------------------- Network -----------------------------------
#
# Set the bind address to a specific IP (IPv4 or IPv6):
#
network.host: 172.29.225.32
#
# Set a custom port for HTTP:
#
http.port: 9200

Em seguida, gerou minha configuração de SSL. Estou usando a conexão baseada em IP:

vim /etc/pki/tls/openssl.cnf
'''
[ v3_ca ]
subjectAltName = IP:172.29.225.32
'''

Então eu gerou meus certificados.

openssl req -config /etc/pki/tls/openssl.cnf -x509 -days 3650 -batch -nodes -newkey rsa:2048 -keyout /etc/pki/tls/private/logstash-forwarder.key -out /etc/pki/tls/certs/logstash-forwarder.crt

Estou usando batidas. Então minha configuração beats é:

input {
  beats {
    port => 5044
    ssl => true
    ssl_certificate => "/etc/pki/tls/certs/logstash-forwarder.crt"
    ssl_key => "/etc/pki/tls/private/logstash-forwarder.key"
  }
}

Eu então instalei o beats e o configurei:

vim  /etc/filebeat/filebeat.yml
'''
output:

  ### Elasticsearch as output
  elasticsearch:
    hosts: ["172.29.225.32:9200"]
  tls:
    certificate_authorities: ["/etc/pki/tls/certs/logstash-forwarder.crt"]
  logstash:
    hosts: ["172.29.225.32:5044"]
'''

Quando eu começo o filebeat, recebo o erro ERROR ::

# systemctl status filebeat
● filebeat.service - filebeat
   Loaded: loaded (/usr/lib/systemd/system/filebeat.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2017-06-09 13:45:35 GMT; 5s ago
     Docs: https://www.elastic.co/guide/en/beats/filebeat/current/index.html
 Main PID: 27273 (filebeat)
   CGroup: /system.slice/filebeat.service
           └─27273 /usr/bin/filebeat -c /etc/filebeat/filebeat.yml

Jun 09 13:45:35 supportserver /usr/bin/filebeat[27273]: transport.go:125: SSL client failed to connect with: x509: cannot validate certificate for 172.29.225.32 because it doesn't contain any IP SANs
Jun 09 13:45:35 supportserver /usr/bin/filebeat[27273]: transport.go:125: SSL client failed to connect with: x509: cannot validate certificate for 172.29.225.32 because it doesn't contain any IP SANs
Jun 09 13:45:36 supportserver /usr/bin/filebeat[27273]: transport.go:125: SSL client failed to connect with: x509: cannot validate certificate for 172.29.225.32 because it doesn't contain any IP SANs
Jun 09 13:45:38 supportserver /usr/bin/filebeat[27273]: transport.go:125: SSL client failed to connect with: x509: cannot validate certificate for 172.29.225.32 because it doesn't contain any IP SANs

Procuro nos vastos espaços da internet uma alternativa para gerar os certs. O que acabei fazendo é:

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

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

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.29.225.32
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: 365
Common name: 
DNS SANs:
    None
IP SANs:
    172.29.225.32

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 copiei esses certs para o caminho correto e ainda estou recebendo o mesmo ERRO. Existe algo que eu perdi?

Quando tento me conectar usando openssl , obtenho:

# openssl s_client -showcerts -connect 172.29.225.32:9200
CONNECTED(00000003)
139677497968544:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 247 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

Alguma ideia?

    
por Jason Stanley 09.06.2017 / 15:52

1 resposta

0

Se eu estiver lendo suas configurações corretamente, os eventos de caminho seguirão aproximadamente:

beats
    |-> elasticsearch 172.29.225.32:9200
    |-> logstash 172.29.225.32:5044
           |-> Points unknown.

Seu teste openssl foi feito contra o ElasticSearch, que, até onde posso dizer, nunca foi configurado para o TLS. Infelizmente, as mensagens de erro que o filebeat está produzindo não são detalhadas o suficiente para separar problemas relacionados ao Logstash de problemas relacionados ao Elasticsearch (porta 9200). Para testar, eu removeria um ou outro da configuração do seu banco de dados e veria como isso afeta os erros; isso é para isolar qual componente está gerando os erros do TLS.

Eu acredito que o padrão de arquivos é não-TLS para o ElasticSearch, a menos que você diga explicitamente para usar o TLS.

A saída logstash para filebeat também parece ser padrão para não-TLS, mas algo na sua configuração está negociando e falhando, ou está estranhamente esperando quando não deveria.

Tendo feito recentemente uma rodada de depuração da SAN, aqui está uma dica útil para tirar as SANs de um certificado:

openssl s_client -connect 172.29.225.32:5044 | openssl x509 -text -noout

Isso lhe dará as SANs no certificado, onde geralmente o s_client geralmente não.

    
por 12.06.2017 / 19:06