Can I have certs generated in different machines with same properties

Hi,

I have a requirement where Elastic will be on one machine and my application will be on other machine, can I generate certs on both the machines with same properties i.e., same org, node-name, password and node_dns name etc and use admin, truststore and node certs of machine1 and transport and truststore certs of machine2

Thanks

Elastic - 5.5.1

Searchguard -5

JDK-1.8

Windows server 2012 R2 Standard

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.

···

On Tuesday, February 20, 2018 at 5:05:33 PM UTC+1, Navakanth.borra@hexagonsi.com wrote:

Hi,

I have a requirement where Elastic will be on one machine and my application will be on other machine, can I generate certs on both the machines with same properties i.e., same org, node-name, password and node_dns name etc and use admin, truststore and node certs of machine1 and transport and truststore certs of machine2

Thanks

Elastic - 5.5.1

Searchguard -5

JDK-1.8

Windows server 2012 R2 Standard

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.

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, Navakanth.borra@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.

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.

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.borra@hexagonsi.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.

Ok, we wont be hosting the elastic, we deliver our product to client and they have to host it, likewise we will be having n number of customers.
Earlier in our workflow when the user installs elastic from our application then we used to generated certs and place node, admin and truststore.jks certs in config folder and the user has to manually copy the transport and truststore.jks to another machine where our application is installed and application talks to elastic via Transport, everything was fine when the use case was like this.

But now the requirement got changed where user should not copy the certs manually…

···

On Friday, February 23, 2018 at 10:44:35 PM UTC+5:30, Jochen Kressin wrote:

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, Navakan...@hexagonsi.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.

Well I can’t tell you how to best implement the installation process of your application, I can only advice on general TLS requirements and workflows. So:

All certificates on all machines have to be trusted by one of the root CAs in the truststore. In order to achive that, they need to be signed by this root CA. Clearly, you want to create a self-signed CA for each customer and not ship any CA with private key with your product, since that would be horrible from a security perspective.

This means the CA has to be generated on-the-fly when installing your product. This is what happens on machine 1. Now in order to use that self-signed root CA on machine 2, it has to be reachable from this machine in some way. If you do not have it on machine 2, or to put it another way, if machine 2 is not able to get it from machine 1, then you have a problem. Without a common root CA (or intermediate/signing CA for that matter) TLS cannot work. (Note that you can have more than one root CA in any truststore, however, that does also not solve the problem).

···

On Sunday, February 25, 2018 at 6:19:45 PM UTC+1, Navakanth B wrote:

Ok, we wont be hosting the elastic, we deliver our product to client and they have to host it, likewise we will be having n number of customers.
Earlier in our workflow when the user installs elastic from our application then we used to generated certs and place node, admin and truststore.jks certs in config folder and the user has to manually copy the transport and truststore.jks to another machine where our application is installed and application talks to elastic via Transport, everything was fine when the use case was like this.

But now the requirement got changed where user should not copy the certs manually…

On Friday, February 23, 2018 at 10:44:35 PM UTC+5:30, Jochen Kressin wrote:

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, Navakan...@hexagonsi.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.