Encrypt filebeat to logstash

I have a small setup. Filebeat was able to successfully send logs to logstash. I was then asked to encrypt communication between filebeat to logstash.

On logstash I've added to the following to the input{ } block:

ssl_certificate => "/usr/share/elasticsearch/elk.crt"
ssl_key => "/usr/share/elasticsearch/elk.key"

I've copied the elk.crt and elk.key to one of the servers that ship logs with filebeat under /etc/elk/certs, and then, in filebeat.yml, under output.logstash:, I've added the following:

hosts: ["91.239.19.210:5044"] # this line was there before. also not the real ip
ssl.certificate: "/etc/elk/certs/elk.crt"
ssl.key: "/etc/elk/certs/elk.key"

When I start filebeat, I endlessly get the following message:

 2020-07-28T16:36:19.644Z        ERROR   [publisher_pipeline_output]     pipeline/output.go:155  Failed to connect to backoff(async(tcp://91.239.19.210:5044)): x509: cannot validate certificate for 91.239.19.210 because it doesn't contain any IP SANs

I thought that maybe it wanted to have a hostname instead of IP, so I added to /etc/hosts:

  91.239.19.210 elk.com

And in filebeat.yml replace the IP with:

 hosts: ["elk.com:5044"]

Which results this error:

 2020-07-28T16:42:12.174Z        ERROR   [publisher_pipeline_output]     pipeline/output.go:155  Failed to connect to backoff(async(tcp://elk.com:5044)): x509: certificate is not valid for any names, but wanted to match elk.com

I'm sitting on this forever and I can't seem to crack it. Does anyone know what's wrong? I feel like I'm missing something. Thanks ahead.

OK, that is saying that you cannot use that certificate when you configure hosts as an IP address because the certificate does not have a Subject Alternate Name that contains an IP address.

I wonder if that could be something like this issue. Hard to tell without seeing all the (non-secret) parts of the certificate.

Thanks for the response.

the certificate does not have a Subject Alternate Name that contains an IP address.

I didn't really get this part, does it mean it only accepts hostnames, instead of IPs?

Well the RFCs allow a certificate to be issued in the name of an IP address, but issuing certificate authorities impose strict conditions on these, and not all clients support them. The more common way to use an IP address in TLS is SAN. Subject Alternate Name records allow a certificate to list multiple alternate hostnames and/or IP address that the certificate should also match.

1 Like

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.