cannot validate certificate - doesn't contain any IP SAN

Question

I am currently in the process of installing ELK ( ElastricSearch, LogStash & Kibana) stack.

My ELK server IP address is 172.29.225.32.

Elastic Search config is ::

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

Then I generated my SSL config. I am using IP based connection :

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

Then I generated my certs.

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

I am using beats. So my beats config is ::

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

I then installed beats and configured it ::

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

When I start filebeat, I get the 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

I search in the vast spaces of the internet of an alternative to generate the certs. What I ended up doing is :

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

I copied these certs to the correct path and still am getting the same ERROR. Is there something that I have missed ?

When I try to connect using openssl I get :

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

Any ideas ?

Solution

If I'm reading your configs right, the path events follow is roughly:

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

Your openssl test was done against ElasticSearch, which as far as I can tell hasn't ever been configured for TLS. Unfortunately, the error messages filebeat is producing are not detailed enough to separate problems talking to Logstash from problems talking to Elasticsearch (port 9200). To test, I would remove one or the other from your filebeat config and see how that affects the errors; this is to isolate which component is generating the TLS errors.

I believe filebeat defaults to non-TLS for ElasticSearch unless you explicitly tell it to use TLS.

The logstash output for filebeat also seems to default to non-TLS, but something in your config is either negotiating for it and failing, or is oddly expecting it when it shouldn't.

Having recently done a round of SAN-debugging, here is a useful tip for getting the SANs off of a certificate:

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

That will give you the SANs on the certificate, where straight up s_client generally doesn't.