Hi,
I’m trying to setup SearchGuard on a cluster. Since it’s only for testing purposes, I would rather avoid having to set up TLS at client/http level. I understand that it’s mandatory at transport level.
When I try to use sgadmin.sh to load my configuration into Elasticsearch, the script always ask for certificates. My question is, since I do not have TLS at client level, why does the script need certificates ? Can I avoid providing them ?
Thank you,
Wenceslas des Déserts.
Hi there,
no, you can’t avoid the certificates for sgadmin.
First, sgadmin works on transport level, not HTTP level, that’s why a certificate is mandatory. Second, since changing the internal SG index poses a security thread to the cluster, we need to reliably identify who is trying to change the config.
We’re thinking about an admin role for SG6, but the requirement for providing the cert is most likely not going away in SG5.
If you just need a quick way of generating certificates, you can always use our TLS certificate generator on our website:
On Tuesday, May 30, 2017 at 3:11:04 PM UTC+2, Wenceslas des Deserts wrote:
Hi,
I’m trying to setup SearchGuard on a cluster. Since it’s only for testing purposes, I would rather avoid having to set up TLS at client/http level. I understand that it’s mandatory at transport level.
When I try to use sgadmin.sh to load my configuration into Elasticsearch, the script always ask for certificates. My question is, since I do not have TLS at client level, why does the script need certificates ? Can I avoid providing them ?
Thank you,
Wenceslas des Déserts.
Hi,
I understand the security concern (and agree). Didn’t realized that sgadmin was working at transport level.
Thank you
By the way, I actually used your tls-certificate-generator but had to disable hostname verification. It seems that the plugin was expecting IP addresses of the nodes to be written somewhere in the certificates…
Hm … thanks for the hint! Hostnames in the certificates should also work, given they match the actual host. We’ll look into this!
On Wednesday, May 31, 2017 at 3:26:27 PM UTC+2, Wenceslas des Deserts wrote:
Hi,
I understand the security concern (and agree). Didn’t realized that sgadmin was working at transport level.
Thank you
By the way, I actually used your tls-certificate-generator but had to disable hostname verification. It seems that the plugin was expecting IP addresses of the nodes to be written somewhere in the certificates…
Honestly, I could as well be wrong about the origin of the issue.
Exception raised by ES :
Caused by: java.security.cert.CertificateException: No subject alternative names matching IP address XX.XX.XX.XX found (XX was an IP corresponding to another node)
On your website, I entered FQDN.
Certificate subject is simply the FQDN (well, CN=FQDN actually). Subject alternative name extensions’ field contains “dns name” (FQDN again) and OUID 1.2.3.4.5.5 .
Hope it can help you ! 
You need to connect via the hostname (not the IP). If you have no hostnames you can naturally not use “hostname” verification.
Then you have to disable it (add -nhnv to the sgadmin command).
Please post your elasticsearch.yml and the sgadmin command.
On Wednesday, 31 May 2017 18:10:21 UTC+2, Wenceslas des Deserts wrote:
Honestly, I could as well be wrong about the origin of the issue.
Exception raised by ES :
Caused by: java.security.cert.CertificateException: No subject alternative names matching IP address XX.XX.XX.XX found (XX was an IP corresponding to another node)On your website, I entered FQDN.
Certificate subject is simply the FQDN (well, CN=FQDN actually). Subject alternative name extensions’ field contains “dns name” (FQDN again) and OUID 1.2.3.4.5.5 .
Hope it can help you !
I think there is a little misunderstanding here. This problem appeared when launching all the nodes with TLS enabled between them. No sgadmin involved (yet).
elasticsearch.yml is standard, just added these lines :
searchguard.ssl.transport.enabled: true
searchguard.ssl.transport.keystore_filepath: (keystore_path)
searchguard.ssl.transport.keystore_password: (pwd)
searchguard.ssl.transport.truststore_filepath: (trustore_path)
searchguard.ssl.transport.truststore_password: (pwd)
searchguard.ssl.transport.enforce_hostname_verification: false #Adding this solved the issue
Oh, just realized that discovery.zen.ping.unicast.hosts field was filled with IP adresses. I guess this is why it was not working…