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

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

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 ответ

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

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

Другие вопросы по тегам