I think you’re confusing some things here, or I don’t fully understand your use case.
Let’s say you do not have any certificates yet and want to setup an Elastic cluster and access it from another machine via Transport. The first thing you need is a root CA, and you can simply generate one by using OpenSSL, as we do in the demo scripts. In order to make things easier, let’s assume we are not using an intermediate / signing cert.
When you create the root CA, you also create a private key for it. This key must be kept secret and confidential and must not be installed anywhere! The only thing that you ship in your truststore or as PEM regarding the root CA is its public certificate, nothing else. This public certificate is imported into a truststore or configured as PEM certificate, so you can verify and validate all other certificates signed by this CA.
You then use the root CA to sign other certificates, e.g. node certificates or client certificates for the transport client. All certificates need to be signed by the very same root CA. But each of this certificates should have a different DN and if you want to use hostname verification also different hostnames in the SAN section. When you create these leaf certificates, you also generate individual keys for them. So, all keys have to be different of course.
If one could simply generate leaf certificates without having access to the root CA, then the complete mechanism would make no sense. It’s basically the same as if you want to have a certificate for a webserver:
You create a private key on your machine and use this key to create a certificate signing request. You send the CSR to the certificate authority. This authority is in possession of the key for their root CA. They sign your CSR, and you get back your certificate and their root CA with their public key. Or the root CA is already installed in your browser.
How to best implement the installation process of your own product I can’t say, it depends on your use case and what user experience you want to provide.
On Friday, February 23, 2018 at 5:24:39 PM UTC+1, Navakanth.email@example.com wrote:
Ok Thanks, I have modified the script to use same PrivateKey every time and I see it working now, but we delivery our product to multiple customers so the user has to setup elastic(from our application where we will be configuring searchguard) in one machine say Machine-1 and our Application on another machine say Machine-2.
But if all the users have same PrivateKey then every user having certs can access every other user elastic, how to avoid impersonation here.
In our application when the user runs the command of our application to install Elastic then we are using searchguard script to generate certs with Machine-1(machine name) and password and signing it with the CA and in the Machine-2 when user runs the command to install our application even at that time we are running searchguard scripts with same Machine-1(machine name) and password and signing it with the same CA used in Machine-1, now application uses the Transport and truststore.jks generated in Machine-2 to talk to elastic via Transport
On Wednesday, February 21, 2018 at 8:45:38 PM UTC+5:30, Jochen Kressin wrote:
Ok, I see. So, in that case, you need to generate a certificate and sign it with the same CA that you configured on your Elasticsearch nodes. When the Transport Client talks to Elasticsearch, you need to add the Search Guard Plugin and the certificate to your settings when building the Transport Client. It then sends its certificate along with the request, and we validate it against the configured root CA (and intermediate CAs, should you use any). Only if the certificate can be verified against this CA it is deemed valid.
On Wednesday, February 21, 2018 at 4:10:24 PM UTC+1, Navakan...@hexagonsi.com wrote:
Yes, application talks to elastic via Transport
On Wednesday, February 21, 2018 at 3:30:24 PM UTC+5:30, Jochen Kressin wrote:
I don’t fully understand the question. When you say your application is on another machine, what kind of application do you mean? Does it talk to Elastic via REST or via Transport?
But generally speaking, no, that is not how TLS works. TLS is based on a chain of trust, which means that for certificates to be valid they need to be signed by a common root or intermediate CA. Let’s say you have two nodes in your cluster, then you need to have a root or intermediate CA, and two certificates signed by that CA. The root / intermediate CA is placed in the truststore. You need to have the same truststore on each node. The node certificates are then validated against this root / intermediate CA.