I am trying to see if this is possible. We are planning to use SG-SSL for securing only the transport layer. However, I want to use only 1 certificate and put all the node’s DNS names under that certificate and use it for both truststore and keystore on all the nodes. Is this possible? This will on windows 2008 R2 and 2012 servers.
Search Guard and Elasticsearch version - 5.5.1
Installed and used enterprise modules, if any - SG SSL
JVM version and operating system version - 1.8.0_131
Yes that should be possible, but of course it’s not optimal from a security point of view. But, technically speaking, yes.
···
On Sunday, October 29, 2017 at 11:51:54 PM UTC+1, askids wrote:
hi,
I am trying to see if this is possible. We are planning to use SG-SSL for securing only the transport layer. However, I want to use only 1 certificate and put all the node’s DNS names under that certificate and use it for both truststore and keystore on all the nodes. Is this possible? This will on windows 2008 R2 and 2012 servers.
Search Guard and Elasticsearch version - 5.5.1
Installed and used enterprise modules, if any - SG SSL
JVM version and operating system version - 1.8.0_131
Thanks for your reponse. Can you also please shed some light on the downside in taking this approach? We plan to have hostname validation enabled. So wanted to understand what are the drawbacks in taking this approach.
Thanks!
···
On Wednesday, November 1, 2017 at 3:03:35 PM UTC-4, Jochen Kressin wrote:
Yes that should be possible, but of course it’s not optimal from a security point of view. But, technically speaking, yes.
On Sunday, October 29, 2017 at 11:51:54 PM UTC+1, askids wrote:
hi,
I am trying to see if this is possible. We are planning to use SG-SSL for securing only the transport layer. However, I want to use only 1 certificate and put all the node’s DNS names under that certificate and use it for both truststore and keystore on all the nodes. Is this possible? This will on windows 2008 R2 and 2012 servers.
Search Guard and Elasticsearch version - 5.5.1
Installed and used enterprise modules, if any - SG SSL
JVM version and operating system version - 1.8.0_131
Well, simple, it’s less secure and inflexible. Usually, you would use:
A root CA
One or more intermediate CAs
One leaf certificate signed by the intermediate CA per node
Reasons are manyfold, but for example:
If you want to add more nodes to the cluster, you simply create additional certs signed by the intermediate CA and be done with it: You don’t need to touch any existing nodes in the cluster. With your approach, you would need to add the new hostname(s) to your single cert, update it on all nodes and then perform a full cluster restart. Rolling restart does not work since you need to exchange the certificate in the truststore as well.
You can, of course, use wildcard certs, but if this certificate gets lost, an attacker can simply use it to fire up additional nodes and gain access to your cluster. Hostname verification would not work in this case either.
Also, once your certificate expires, you also need to perform a full cluster restart due to the above.
···
On Thursday, November 2, 2017 at 4:41:50 AM UTC+1, askids wrote:
Thanks for your reponse. Can you also please shed some light on the downside in taking this approach? We plan to have hostname validation enabled. So wanted to understand what are the drawbacks in taking this approach.
Thanks!
On Wednesday, November 1, 2017 at 3:03:35 PM UTC-4, Jochen Kressin wrote:
Yes that should be possible, but of course it’s not optimal from a security point of view. But, technically speaking, yes.
On Sunday, October 29, 2017 at 11:51:54 PM UTC+1, askids wrote:
hi,
I am trying to see if this is possible. We are planning to use SG-SSL for securing only the transport layer. However, I want to use only 1 certificate and put all the node’s DNS names under that certificate and use it for both truststore and keystore on all the nodes. Is this possible? This will on windows 2008 R2 and 2012 servers.
Search Guard and Elasticsearch version - 5.5.1
Installed and used enterprise modules, if any - SG SSL
JVM version and operating system version - 1.8.0_131