a typical setup would be to use certificates signed by a well-known CA like Thawte or Comodo on the REST layer to avoid the browser warnings for self-signed certificates. On the transport layer, you can safely use self-signed certificates, for example, generated by the offline TLS Tool. This includes the admin certificate as well.
You would then configure the transport and REST layer with these certificates on elasticsearch.yml. If you have an intermediate certificate you would add it to the file containing your lead certificate (the wildcard cert for your domains).
If you want to only use Comodo as CA, then you would need two certificates from them, both signed with the same root and intermediate CA. One certificate to use on the transport and REST layer, and one certificate you can use as admin certificate. For security reasons, you cannot use a node certificate as admin certificate at the same time.
On Thursday, September 27, 2018 at 9:10:49 AM UTC+2, Richard Newman wrote:
It looks like a similar question has been asked here so I’ll user that for reference in the first instance
On Thursday, 27 September 2018 16:53:19 UTC+10, Richard Newman wrote:
The setup guide is great to get you started. Using the demo certs and then creating self-signed certs has been straight forward. We’d now like to use certs signed by our CA (Comodo) and provided by DNSimple.
They provide a primary certificate and intermediate certificates along with a .key file (for all). This doesn’t seem to correlate to what is required in the elastic config. Can I use these certificates? The primary certificate is a wild card for our domain so can cover all the nodes. Do we need to generate a admin cert using the offline tool? This wouldn’t work as it hasn’t been signed. Would we need to make separate requests to our certificate provider to generate all the relevant (additional) certs?