Need help in configuring TLS/SSL for ELK with 3rd party certificates (comodo)

Elastic Stack Elasticsearch
1

Hi Team,
Need your help, I was successfully able to manage/configure TLS/SSL with self signed pk12 certs. Now I purchased cert(pem) single pem file with SAN ( having 43 hosts DNS and ips) .I have pem format cert, cert format, dar format and P7B format.
I am not able to configure the elastic with these and I see its failing while trying to set the password . I have followed the link below: https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-tls.html#node-certificates
I am not able to understand the input line (shown below, what should be given here )"xpack.security.transport.ssl.certificate_authorities: [ "/home/es/config/ca.crt" ]"
Please let me know if any questions, and any help would be great help to me.
Thanks
Suddhasil

2

You probably don't want to actually use a commercial certificate for transport.ssl (port 9300)

You probably do want to use it for http.ssl, but for transport your best option is to stick with the certificate you originally generated.

Transport SSL & Cluster Membership

The security of your cluster requires that you control which nodes are able to join the cluster. If another person is able to start a node on a host that they control, and connect it to your cluster then they have full access to all of your data (for example, they can extract it all, and then delete it from your cluster).
If unauthorized nodes are able to join your cluster, then it defeats all of the other security controls that you might put in place.

Elasticsearch Security offers 2 ways to restrict cluster membership:

  • IP Filters
  • TLS certificates

IP Filters are an option for some environments, but they have some weaknesses, and we recommend using certificates as your primary cluster membership control. Without going into too much detail, the issues with relying on IP filters are:

  1. They are based on IP address only (not ports), so they require that you have full confidence on everything running on that IP address
  2. They require that your nodes have fixed IP addresses, or that you place complete trust in a range of IP addresses (and can be 100% sure that no one else can ever run a node on a machine in that range).
  3. They require a Gold license or higher - which is fine if you are a paying customer, but means it's not an option for people relying on our free security features.

For the above reasons, we recommend that you use TLS certificates as the primary mechanism by which you restrict cluster membership. IP Filters are a great secondary control, to provide defense-in-depth for your cluster membership.

Transport TLS Certificates can be used to control the cluster membership by requiring that every node presents a trusted certificate when attempting to join the cluster (this is true by default when you enable transport.ssl) and then restricting the set of certificates that you trust to exactly match with your intended cluster membership.

The only reasonable way to do that is to have a dedicated Certificate Authority for your cluster. Each of your nodes trusts that CA and then you ensure that this CA (that you control) only ever issues certificates to nodes that are supposed to join your cluster. That is, you place tight controls around the set of certificates that the CA issues so that you can confidently say If a node can prove ownership of a certificate that was issued by my CA then that is sufficient proof that the node should be allowed to join the cluster.

You cannot make that statement if you use a commercial CA, or even a corporate CA. Those CAs issue certificates to all sorts of people for all sorts of purposes. You cannot confidently state that If a node has a valid certificate issued by {IdenTrust/DigiCert/LetsEncrypt} then it should be allowed to join my cluster because that would essentially open the cluster to everyone.

HTTP Certificates

None of the above analysis is true for HTTP (xpack.security.http.ssl). The certificates that you use on that port (by default, 9200) do not control membership to your cluster, they are used when REST clients connect to your nodes.

For that purpose, it is helpful to use a central (commercial, community or corporate) CA so that you clients can rely on their existing TLS trust stores in order to trust your Elasticsearch service.

1 Like
3

Thanks Tim, this helps. Could you please suggest me what I need in order to place the cert request for HTTP communication? I have used the same cert but still its failing. I have a cert ( pem format ) with me, I have key . What else need ? what should I use for the entry : "xpack.security.http.ssl.certificate_authorities " ?
Please suggest

Thanks
Suddhasil

4

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.