There are actually two questions here:
- Should I use the same certificates for
- 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:
- 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).
- 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.
- The certificate formats only need to work within Elasticsearch (not Kibana, Beats, or custom clients).
- The certificate only needs server usage. It's never used as the client.
- You want the certificate to be trusted by a lot of clients. Kibana, Beats, Curl, custom apps/services built using official language clients, etc.
- 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.