Encrypting HTTP client communications

[ehsan_kabiri_33 (Ehsan)]

According to elasticsearch reference [7.12] , as I understood,
we can encrypt HTTP client communications with any of the following .p12 certificates:

First option : use the same certificate which I have used for encrypting communications between nodes in a cluster , it is generated by following codes:

./bin/elasticsearch-certutil ca
./bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12

Second option: Generate additional certificates specifically for encrypting HTTP client communications like this:

./bin/elasticsearch-certutil http

both of them works, but I can't understand why should I use the second ?

[TimV (Tim Vernum)]

There are actually two questions here:

1. Should I use the same certificates for transport.ssl and http.ssl ?
2. Should I use the cert sub-command or the http sub-command to generate certificates for HTTP.

You should use whatever works for you.

Generally speaking, you should think about transport and HTTP certificates as different things, solving different problems. If 1 single certificate works for you and solves both those problems, then that's great, but that's often not the case.

For transport, you want these properties:

1. The certificates work for both client and server usage (because the connections between nodes are bi-directional, and Elasticsearch uses mutual-TLS for those transport connections).
2. The set of trusted certificates are as small as possible - that's why we recommend you have a custom CA for each deployment. This trust setup is how you control which nodes can join your cluster, so you want to trust exactly the right certificates and nothing else.
3. The certificate formats only need to work within Elasticsearch (not Kibana, Beats, or custom clients).

For HTTP:

1. The certificate only needs server usage. It's never used as the client.
2. You want the certificate to be trusted by a lot of clients. Kibana, Beats, Curl, custom apps/services built using official language clients, etc.
3. If you have a custom CA, then you need it to be available in a variety of formats so it can be imported into all of those different clients.

If you generate a custom CA & certificate with elasticsearch-certutil ca & elasticsearch-certutil cert, then it will satisfy the 3 points for transport - it will support server & client usage, it will have a custom CA, and it's in a single working format.

You can then use it for HTTP, but there are limitations. The fact that the cert works as a client cert isn't a problem, but the custom CA means no other clients trust it, you need to configure each of them, and the elasticsearch-certutil cert command will produce a PKCS#12 file and not all clients support that format.

elasticsearch-certutil http is designed to do a better job of the HTTP specific needs. If you're happy using your transport certificates for HTTP, that's totally fine.