Beats SSL question

Elastic Stack Beats
1

Hello all,

I would just like to clarify if I understand this correctly. In the documentation it states that to use client certificate validation the SSL certificates need to be signed directly by the root ca.

So, if I have a client certificate with the path (Root CA) -> (Issuing CA) -> (Client Certificate) this is not going to work?

First, I used an SSL client certificate on the logstash side, with the winlogbeat side config using only certificate_authorities for ssl checking. It was working ok. Now I'm trying to setup a client certificate for the winlogbeat, but it´s not connecting anymore. I'm trying to figure out if it is normal since my certificate is not signed directly by the rootCA or is my understanding of how to set it up somehow wrong. I'm using the same IssuerCA for all examples. I also tested the connectivity with curl and it looks ok.

Thank you in advance for help.

Kind regards,

Uros

2

Hi Uros,

Have you had a look at anti virus or firewall apps on the Windows machine? Try excluding the Winlogbeat folder. This worked for me.

IMO: I do not believe the documentation is aimed at enterprise solutions and I think certs are best served by an existing CA within your network. Manually copying and moving certificates is clumbersum.

Logstash or Elasticsearch and encryption? Not sure what your set-up is and I'm new to this myself but I was advised to send Windows beats direct to Elasticsearch on the ELK stack. However yet to get that working because I am stuck in template hell! The reason why I mention it, is because I think this can use HTTPS. https://www.elastic.co/guide/en/beats/winlogbeat/master/securing-communication-elasticsearch.html

Paul

3

Hey Paul,

thanks for your answer.

After some more troubleshooting, I found out that the problem was with ssl_verify_mode in my logstash config. I have set it to force_peer and it somehow doesn't like my settings. Probably something not resolving or I have to add something like the IP or something to the client certificate. If I set it to just "peer" it works. Yey.

I don't quite understand what the difference regarding the certificate checking between the settings "force_peer" and only "peer" is.

Kind regards,
Uros

4

No problem Uros glad to know that you fixed it. Any chance of sharing your logstash config? I haven't come across the "peer" setting yet, might be good to share.

5

There are 3 different modes for client auth. 'none', 'peer' and 'force_peer'. The 'peer' option is kind of optional, but ignores client_authentication at will.

I think the jruby SSL implementation has a bug not correctly verifying certificates if intermediates are used.

6

@steffens: So, if I set it to peer it will not use SSL client authentication, but the transport is still encrypted. Not quite the solution I was looking for. I need to have client authentication working. I will try to set up my own CA (without any intermediates) and test the config with new certs and force_peer.

@dickepa: the setting is ssl_verify_mode for the beats input plugin. This is my test logstash config just for testing this ssl stuff. It is quite basic:

beats {
port => 5044
ssl => true
ssl_verify_mode => peer
ssl_certificate_authorities => ["/etc/pki/root-ca.cer", "/etc/pki/xxxxxx.cer"]
ssl_certificate => "/etc/pki/xxxxxxxx.xxx.local.cer"
ssl_key => "/etc/pki/xxxxxxxxx.xxxx.local.key"

}

7

Just a follow up...

I set up my own CA and behold everything started to work as expected. Even with the force_peer option set. The only problem I stumbled upon was self inflicted, because I issued the certificate got winlogbeat as a server certificate and it failed at handshake. Reissued as a client certificate and voila. Everything perfect.

On the intermediate CA regard, when is this going to be supported in jruby? Anyone knows? There seems to be a lot of docs that state that using intermediate CAs to sign certificates is best practise.

Kind regards,

Uros

8

No idea about the jruby part. I was told there has been a pull request fixing the issue, but it was not merged.

It's a known issue taken care of by logstash team, but I've no idea when this will be fixed.

9

Just an update (again). :slight_smile:

Your link actually took me to the solution for my problem. There is a ticket open for clarification of this behaviour and there is also a workaround (sort of) posted in the ticket. If you merge all the certificates in the chain to one file it works even if you are using intermediate CAs.

I have tested it in my environment and it works!

Thanks.

Kind regards,
Uros

1 Like
10

Awesome, thanks!