Назад | Перейти на главную страницу

не может проверить сертификат - не содержит IP SAN

В настоящее время я устанавливаю стек ELK (ElastricSearch, LogStash & Kibana).

IP-адрес моего сервера ELK 172.29.225.32.

Конфигурация эластичного поиска:

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

Затем я создал свою конфигурацию SSL. Я использую IP-соединение:

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

Затем я создал свои сертификаты.

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

Я использую биты. Итак, моя конфигурация 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"
  }
}

Затем я установил beats и настроил его:

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"]
```

Когда я запускаю filebeat, я получаю ОШИБКУ:

# 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

Я ищу на просторах Интернета альтернативу генерации сертификатов. В итоге я сделал следующее:

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

Я скопировал эти сертификаты на правильный путь и все еще получаю ту же ОШИБКУ. Что-то я пропустил?

Когда я пытаюсь подключиться, используя openssl Я получил :

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

Любые идеи ?

Если я правильно читаю ваши конфиги, события следуют примерно так:

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

Ваш тест openssl был проведен против ElasticSearch, который, насколько я могу судить, никогда не настраивался для TLS. К сожалению, сообщения об ошибках, которые генерирует filebeat, недостаточно подробны, чтобы отделить проблемы, связанные с разговором с Logstash, от проблем, связанных с Elasticsearch (порт 9200). Для проверки я бы удалил один или другой из вашей конфигурации filebeat и посмотрел, как это повлияет на ошибки; это необходимо для того, чтобы определить, какой компонент генерирует ошибки TLS.

я верить filebeat по умолчанию не использует TLS для ElasticSearch, если вы явно не укажете ему использовать TLS.

В logstash вывод для filebeat также, кажется, по умолчанию не-TLS, но что-то в вашей конфигурации либо согласовывает это и не работает, либо странно ожидает этого, когда этого не должно быть.

Недавно выполнив раунд отладки SAN, вот полезный совет по отключению SAN от сертификата:

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

Это даст вам SAN в сертификате, в то время как s_client обычно не работает.