I'm new to ELK Stack so I'm not sure if this issue is actually with Winlogbeat itself or with Logstash. Here is what is happening:
I have an ELK stack server running on CentOS 7 in pretty much a default configuration. In my environment I have a private Root and Intermediate CA setup so I used the Intermediate to sign the certificate being used for TLS by Logstash.
The Root and Intermediate CA have SHA2-512 signatures with ECC public keys. OpenSSL identifies the signature algorithm as "sha512WithRSAEncryption" and the public key algorithm as "id-ecPublicKey".
I am configuring Winlogbeat on a WIndows 2012R2 server in this environment. I can access Kibana on the Windows server via HTTPS and TLS works fine. (Naturally the certificates for the Intermediate and Roots have to installed on the HTTPS client for it to trust them.) However Winglogbeat fails to connect if TLS is enabled and insecure: true" is disabled under output\logstash\tls. It will connect if I comment this out.
The error in the log is :
ERR SSL client failed to connect with: x509: certificate signed by unknown authority (possibly because of "x509: cannot verify signature: algorithm unimplemented" while trying to verify candidate authority certificate "Intermediate CA")
Unfortunately my Linux fu is not nearly strong enough to know where/how/if I can make such a change myself. I'd appreciate any input on this that will help me resolve the issue.
You can test the theory by adding _ "crypto/sha512" to the imports in libbeat/outputs/transport/tls.go. This will have the side effect of registering the hash functions. Then you will need to rebuild the beat. There is some guidance in the contributing guide.
If you building Winlogbeat on Linux, you can run GOOS=windows make in the winlogbeat directory to generate the winlogbeat.exe for Windows.
Thanks for the information Andrew. I'm using a Windows workstation to try and do this. It does not seem to be working for me but I've never done this before so I'm probably making some very basic mistake(s).
This is what I've done:
Downloaded the elastic/beats repository from Github
Installed Git, GoLang and Python for Windows
Set my GOPATH environment variable to C:\Users\dsalzedo\Documents\Go
Copied the elastic/beats repository to C:\Users\daniel\Documents\Go\src\github.com\elastic\beats
Edited the libbeat\outputs\transport\tls.go file to add the _ "crypto/sha512" entry in the Imports section.
Opened an Admin command prompt in the winlogbeat folder and ran make.bat. The output is as follows:
C:\Users\daniel\Documents\Go\src\github.com\elastic\beats\winlogbeat>make.bat
Building
Testing
'gotestcover' is not recognized as an internal or external command,
operable program or batch file.
A "gotestcover.exe" file is being created by this process in C:\Users\daniel\Documents\Go\bin but it is too small to be the winlogbeat.exe.
The good news is using go build as you suggested worked and I got a new winlogbeat.exe file. However the bad news is that after installing it on my test client it has made no difference. I still get the same error when connecting with TLS to my Logstash server that has a certificate with a SHA512 signature.
I found an alternative solution for this that did not involve modifying the code. I upgraded to v5.0 of ELK stack and deployed the new v5.0.0 version of the winlogbeat to my test client. I copied over the settings I had been using, adjusted for the new .yml file layout.,
Initially it failed just the same if output.logstash\ssl.verification_mode set to full and using the setting output.logstash\ssl.certificate_authorities which is pointing to a local .PEM file containing the public certificates of my intermediate and root CAs with the SHA2-512 signatures. However after removing output.logstash\ssl.certificate_authorities it started working just fine.
The previous release of winlogbeat had been unable to make a TLS connection without the .PEM file setting even though the CA certificates were already installed in the Windows Local Computer certificate store. Do you know if something changed for this release to make this possible?
5.0 was built with a Go 1.7.1 instead of 1.5.1. So there could have been some internal changes to Go that affected certification handling and chain validation. There might be some clues in the Golang release notes or in their issue tracker on Github. Really happy to hear you got it working.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.