не может проверить сертификат - не содержит 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
---

Есть идеи?

1
задан 9 June 2017 в 16:52
1 ответ

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

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 обычно этого не делает.

0
ответ дан 4 December 2019 в 04:51

Теги

Похожие вопросы