More documentation on enterprise-search config options?

Elastic Search
1

I have elasticsearch and enterprise-search both running.
In order to get them running together (with basic license) I had to enable SSL on the elasticsearch side in order to use API key as required by enterprise search (even for localhost connections).

I have a letsencrypt cert that was generated for the public hostname of the box...however I had to turn off enterprise-search's option elasticsearch.ssl.verify. I believe because of mismatched hostnames (localhost vs some-public-host.example.com).

One option would be to have enterprise-search connect via the public hostname rather than localhost... but as most cluster connections will be on internal, non-public hostnames this isn't really a valid solution.

Longer term we will be using our internal CA to sign certificates. I'm trying to understand the impact of the enterprise-search ssl options better. Not for connection to enterprise search as SSL termination is handled by nginx, but for the connection from enterprise-search to elastic-search.

In particular the following config...

# Elasticsearch SSL settings:
#
elasticsearch.ssl.enabled: ${ES_SSL_ENABLED:false}
elasticsearch.ssl.certificate: ${ES_SSL_CERT}
elasticsearch.ssl.certificate_authority: ${ES_SSL_CA}
elasticsearch.ssl.key: ${ES_SSL_KEY}
elasticsearch.ssl.key_passphrase:
elasticsearch.ssl.verify: ${ES_SSL_VERIFY:true}

Just wondering if there is more documentation somewhere about these options. For instance it isn't clear to me why you would share the private key from elastic search with enterprise search.
It also isn't clear how specifying the elastic search ca-chain/cert/key from elastic search with enterprise search impacts the verification.

It also isn't clear what the verification is exactly. Full hostname verification, CA verification, etc. For internal hosts CA or cert verification is usually enough and hostname verification usually causes issues as we may not want to use/maintain DNS records for non-public endpoints (other means of service discovery).

Just hoping someone can point me to more detailed documentation about how these options work so we can have a sane setup for ssl configs. Doesn't seem to be much documentation other than here is the template config files showing all options?

Related topic on other elastic components: Tls verification_mode, custom validation options? - #2 by steffens

2

Hey @matp :

Thanks for bringing this up. Admittedly, SSL settings are a bit confusing. Let me try to clarify them:

elasticsearch.ssl.enabled: SSL communication with Elasticsearch enabled or not.

# The following are client certificate options to use for communicating with Elasticsearch
elasticsearch.ssl.certificate: Path to client certificate file to use for client-side validation from Elasticsearch.
elasticsearch.ssl.key: Path to the key file for the client certificate
elasticsearch.ssl.key_passphrase: Passphrase for the above key file

# Validation of Elasticsearch SSL certificate
elasticsearch.ssl.certificate_authority: Path to the keystore that contains Certificate Authorities for Elasticsearch SSL certificate.
elasticsearch.ssl.verify: true to verify SSL certificate from Elasticsearch, false otherwise.

I haven't tested about hostname validation from the client side. It depends on OpenSSL implementation, and I'd say it is not enabled by default. Can you please check and let me know about your findings?

We'll update the description for the SSL settings in our next documentation releases so they are more straightforward to understand.

Let me know whether this helped!

3

That helps a lot. Definitely makes sense to group these options separately since they are mostly unrelated (client certificate authentication vs server certificate validation).

The verification thing... I will try to test that in more detail next time I am working on this stuff. For now I have left verify disabled since everything is localhost and the firewall isn't open. But for this type of stuff if definitely makes sense to have the option to only do CA/chain verification and not hostname verification (CN/SAN) since these boxes may often talk to each other on private IPs (for example).