Encryption general questions

[rugenl (Len Rugen)]

I'm working on a stack design and have some questions about various ways others have setup encryption.

We are an .edu, so we can get unlimited InCommon certificates for no additional cost.

1. For node-to-node encryption, should we use the certutil or use InCommon?

2. If we use certutil, I think if we generate and save a CA, we can then setup future nodes without having to redo the existing nodes. RIght?

3. I think we should use InCommon certs for HTTP Client and Kibana, since our clients should already have those CA paths.

4. Any other suggestions?

Thanks

[TimV (Tim Vernum)]

@rugenl

For node-to-node encryption, should we use the certutil or use InCommon?

TLS is the primary mechanism by which you can control which nodes are permitted to join your cluster. You can use network controls (e.g. Elasticsearch IP filtering, host based filters or firewalls) but our out-of-the-box solution is TLS certificate controls.

For that to work, you really need to have a dedicated CA for your cluster. That CA can be a root certificate (which is what certutil will generated) or a sub-CA (if you use your own tooling).
This way you know that only nodes that have a certificate that you (that is, your dedicated CA) issued are able to join & be trusted by your cluster.

For simplicity's sake I recommend that you use certutil for that. It's possible to use other tooling instead, but certutil will do the right thing and is tested and supported by Elastic.

@rugenl

f we use certutil, I think if we generate and save a CA, we can then setup future nodes without having to redo the existing nodes. RIght?

That is correct. As long as you hold on to the CA cert + key you can add new nodes whenever you need.
Alternatively you can (if you choose) disable hostname verification and use a single cert across your whole cluster, in which case there's nothing to generate when you add new nodes, you just copy that PKCS#12 file from an existing node to your new node as part of provisioning.

@rugenl

I think we should use InCommon certs for HTTP Client and Kibana, since our clients should already have those CA paths.

Yes. It is simplest to use an existing, trusted CA for all HTTP interfaces.

[rugenl (Len Rugen)]

Thanks, this is the best info we've found on this!

We were making progress until we started trying to use https://localhost:9200. The first app was Kibana, we found a post saying you "must" use

elasticsearch.ssl.verificationMode: certificate

Of course, it didn't say why (I'll bet onlocalhost validation failure), but it lets Kibana mostly work except for monitoring, which is probably these errors:

["license","warning","xpack"],"pid":216709,"message":"License information fr
om the X-Pack plugin could not be obtained from Elasticsearch for the [monitoring] cluster. Error: No Living connections"}

So far I haven't been able to find the equivalent option for xpack monitoring verification mode.

I started working on logstash and got it somewhat working, but it generates so many log messages starting with

** WARNING ** You have enabled encryption but DISABLED certificate verification

that we will drown in our own log volume.

What is the best practice here? While most of our ingest to port 9200 will be from localhost, there may well be some over the network, so it should use TLS. Can "localhost" be added to the cert? (We used an InCommon cert here, it will eventually be a san cert with all the hosts in the stack listed).

We are testing on 6.6.1.

Thanks