Transport TLS problems

Search Guard
1

We don’t want transport TLS. Our whole cluster exists in a private network. Regardless, we try to get it working as its required. Today, I am getting this

Caused by: java.security.cert.CertificateException: No subject alternative DNS name matching poc-profiles-es-01 found.

``

It’s not a sudden error. I’m deploying to a new cluster. After some reading, I put these properties in elasticsearch.yml
searchguard.ssl.transport.enforce_hostname_verification: false

searchguard.ssl.transport.resolve_hostname: false

``

The error remains. I think many people face this same issue. Whether they need TLS or not, I think many people will want to test SG with TLS not being a variable, at some stage.

Question: Without resorting to using the demo scripts, what would be the minimal path to setting up TLS with the goal of not having to think about it.

I fully expect a wave of security concerns coming back, but my question remains.

Please and thank you.

2

For my case, I just needed to make sure the SAN in the node certs was accurate. So, solved.

I still recommend a small education on TLS. I know it’s not your product but it is SO closely tied to it.

In lieu of that, I recommend wrapping up the ‘example’ script bundle into something more practical and non example-like. That’s what I ended up doing in the end: dropping my node info straight into the example scripts.

Thanks,

Marco.

···

On Thursday, September 28, 2017 at 6:17:46 PM UTC+2, mcost...@np6.com wrote:

We don’t want transport TLS. Our whole cluster exists in a private network. Regardless, we try to get it working as its required. Today, I am getting this

Caused by: java.security.cert.CertificateException: No subject alternative DNS name matching poc-profiles-es-01 found.

``

It’s not a sudden error. I’m deploying to a new cluster. After some reading, I put these properties in elasticsearch.yml
searchguard.ssl.transport.enforce_hostname_verification: false

searchguard.ssl.transport.resolve_hostname: false

``

The error remains. I think many people face this same issue. Whether they need TLS or not, I think many people will want to test SG with TLS not being a variable, at some stage.

Question: Without resorting to using the demo scripts, what would be the minimal path to setting up TLS with the goal of not having to think about it.

I fully expect a wave of security concerns coming back, but my question remains.

Please and thank you.

3

Mi Marco,

thanks for your feedback. Regarding TLS being mandatory - well, we’re a “security first” company and have strong opinions on that topic of course.

Search Guard always required TLS on transport level, and even though we got a lot of requests to make it optional, we always stuck to our initial decision. Reason: You will never be able to implement proper security without encrypting the data in transit. It seems that with the release of X-Pack 6 Elastic (finally!) follows our path, since TLS on transport will be mandatory also in X-Pack Security. Better late than never!

A private network alone definitely will not help here, since according to various security studies (e.g. from IBM), more than 50% of the attacks come from the inside, not the outside. That’s why all compliance standards like GDRP, HIPAA, PCI etc. require encryption for data in transit, and sometimes also at rest. The future of Enterprise Security will definitely be “zero trust networks” (e.g. https://cloud.google.com/beyondcorp/) and the least you can do is to encrypt traffic. In my opinion, the days where you could rely on private networks, VPNs, firewalls etc. are definitely over. See for example the OneLogin breaches.

Security in general and TLS in particular is definitely not an easy topic, and if someone tells you his or her security solution just works out of the box - don’t trust them. It just doesn’t. One needs to familiarize with the concepts behind any security solution to make sure it does what it’s supposed to do. We think there is no shortcut to that. For example, in order to execute sgadmin you need to provide a client certificate. This was a deliberate decision because the other option would be to provide a default password or generate a random password upon installation. Default passwords are a no-go, and randomly generated passwords are also insecure. That’s why we took the certificate based approach, even if it is a bit harder to understand than just typing admin/admin :wink:

But having said all that :wink: …

I’m curious about the hurdles you faced when creating the certificates. I always thought that creating certificates for Search Guard is not harder than, say, generating a certificate for a web server. You need to generate a CSR in both cases and submit it to a CA (be it external or your internal PKI). You get back certificates, e.g. in PEM format, and need to configure the cert and the key on the server, which is ES/SG in this case. Also with a web server certificate, you need to make sure to provide the correct information in the CSR, for example, the correct hostname.

We can definitely extend the example scripts, but they surely require Java and OpenSSL installed on the machine where you execute them. For users that cannot use them, we provide the TLS certificate generator service on our website. For companies that have a PKI infrastructure in place, TLS is usually not a problem, and we see more and more companies moving away from traditional user/password based approaches, towards certificates only infrastructure.

So I really like to learn more about the specific issues you faced and the infrastructure you’re working with, so we can improve the whole TLS topic further. You can also take this conversation private if you like by dropping me an email: jkressin@floragunn.com

Thanks for your feedback!

···

On Friday, September 29, 2017 at 2:29:13 PM UTC+2, mcostantini@np6.com wrote:

For my case, I just needed to make sure the SAN in the node certs was accurate. So, solved.

I still recommend a small education on TLS. I know it’s not your product but it is SO closely tied to it.

In lieu of that, I recommend wrapping up the ‘example’ script bundle into something more practical and non example-like. That’s what I ended up doing in the end: dropping my node info straight into the example scripts.

Thanks,

Marco.

On Thursday, September 28, 2017 at 6:17:46 PM UTC+2, mcost...@np6.com wrote:

We don’t want transport TLS. Our whole cluster exists in a private network. Regardless, we try to get it working as its required. Today, I am getting this

Caused by: java.security.cert.CertificateException: No subject alternative DNS name matching poc-profiles-es-01 found.

``

It’s not a sudden error. I’m deploying to a new cluster. After some reading, I put these properties in elasticsearch.yml
searchguard.ssl.transport.enforce_hostname_verification: false

searchguard.ssl.transport.resolve_hostname: false

``

The error remains. I think many people face this same issue. Whether they need TLS or not, I think many people will want to test SG with TLS not being a variable, at some stage.

Question: Without resorting to using the demo scripts, what would be the minimal path to setting up TLS with the goal of not having to think about it.

I fully expect a wave of security concerns coming back, but my question remains.

Please and thank you.

4

Thanks for the great reply. I’ll reply too! I hope my perspective and journey with setting up yields some good things for you guys (although I’m sure you’ve seen it all 100x before). Also, thanks for the great product.

The first thing that should be said is that I effectively have no experience with the inner workings of TLS. I’ve been able to use TLS for HTTP on many projects, but for me, that’s been as easy as requesting certs, and having a hosting provider install them. I am a developer, and I should know this (now is the time!), but as of yet, the inner workings of TLS have escaped me.

Now, I’ve been charged with doing a feasibility test of the authorization features of SearchGuard within our private network. I hope you can see the conflict here right away. We haven’t committed to SG yet, we just wanted to try it out to see what auth looks like with SG.

I’m now going to respond to some of the points you made:

  • I understand that you’ve made TLS mandatory and I understand why. I agree that private networks do not solve the problem.
  • My understanding of TLS was so insufficient that I was not even confident using the online generator. I know it’s dead simple, but when I started, it was all a different language to me.

Back to me:
You guys are the experts on security and your product. However, the inability to temporarily turn off TLS for the purpose of my feasibility test would have saved SO MUCH TIME. That being said, I see an alternative: educate your users on TLS from the perspective of ES and SG. Sure, it may be overkill, but it’s definitely an inclusive move, and after having a few external, personal conversations about this, I have a feeling there are more noobs like me than you think.

I’m taking another look at the online generator. It is mostly what I needed. This plus some entry-level, domain specific docs on TLS with SG and ES. If they exist and I’ve missed them, or skipped them at the time, point them out to me please. I think I’m a good candidate for saying if it is “nooby” enough. :smiley:

Many thanks,

Marco.

···

On Friday, September 29, 2017 at 2:55:32 PM UTC+2, Jochen Kressin wrote:

Mi Marco,

thanks for your feedback. Regarding TLS being mandatory - well, we’re a “security first” company and have strong opinions on that topic of course.

Search Guard always required TLS on transport level, and even though we got a lot of requests to make it optional, we always stuck to our initial decision. Reason: You will never be able to implement proper security without encrypting the data in transit. It seems that with the release of X-Pack 6 Elastic (finally!) follows our path, since TLS on transport will be mandatory also in X-Pack Security. Better late than never!

A private network alone definitely will not help here, since according to various security studies (e.g. from IBM), more than 50% of the attacks come from the inside, not the outside. That’s why all compliance standards like GDRP, HIPAA, PCI etc. require encryption for data in transit, and sometimes also at rest. The future of Enterprise Security will definitely be “zero trust networks” (e.g. https://cloud.google.com/beyondcorp/) and the least you can do is to encrypt traffic. In my opinion, the days where you could rely on private networks, VPNs, firewalls etc. are definitely over. See for example the OneLogin breaches.

Security in general and TLS in particular is definitely not an easy topic, and if someone tells you his or her security solution just works out of the box - don’t trust them. It just doesn’t. One needs to familiarize with the concepts behind any security solution to make sure it does what it’s supposed to do. We think there is no shortcut to that. For example, in order to execute sgadmin you need to provide a client certificate. This was a deliberate decision because the other option would be to provide a default password or generate a random password upon installation. Default passwords are a no-go, and randomly generated passwords are also insecure. That’s why we took the certificate based approach, even if it is a bit harder to understand than just typing admin/admin :wink:

But having said all that :wink: …

I’m curious about the hurdles you faced when creating the certificates. I always thought that creating certificates for Search Guard is not harder than, say, generating a certificate for a web server. You need to generate a CSR in both cases and submit it to a CA (be it external or your internal PKI). You get back certificates, e.g. in PEM format, and need to configure the cert and the key on the server, which is ES/SG in this case. Also with a web server certificate, you need to make sure to provide the correct information in the CSR, for example, the correct hostname.

We can definitely extend the example scripts, but they surely require Java and OpenSSL installed on the machine where you execute them. For users that cannot use them, we provide the TLS certificate generator service on our website. For companies that have a PKI infrastructure in place, TLS is usually not a problem, and we see more and more companies moving away from traditional user/password based approaches, towards certificates only infrastructure.

So I really like to learn more about the specific issues you faced and the infrastructure you’re working with, so we can improve the whole TLS topic further. You can also take this conversation private if you like by dropping me an email: jkre...@floragunn.com

Thanks for your feedback!

On Friday, September 29, 2017 at 2:29:13 PM UTC+2, mcost...@np6.com wrote:

For my case, I just needed to make sure the SAN in the node certs was accurate. So, solved.

I still recommend a small education on TLS. I know it’s not your product but it is SO closely tied to it.

In lieu of that, I recommend wrapping up the ‘example’ script bundle into something more practical and non example-like. That’s what I ended up doing in the end: dropping my node info straight into the example scripts.

Thanks,

Marco.

On Thursday, September 28, 2017 at 6:17:46 PM UTC+2, mcost...@np6.com wrote:

We don’t want transport TLS. Our whole cluster exists in a private network. Regardless, we try to get it working as its required. Today, I am getting this

Caused by: java.security.cert.CertificateException: No subject alternative DNS name matching poc-profiles-es-01 found.

``

It’s not a sudden error. I’m deploying to a new cluster. After some reading, I put these properties in elasticsearch.yml
searchguard.ssl.transport.enforce_hostname_verification: false

searchguard.ssl.transport.resolve_hostname: false

``

The error remains. I think many people face this same issue. Whether they need TLS or not, I think many people will want to test SG with TLS not being a variable, at some stage.

Question: Without resorting to using the demo scripts, what would be the minimal path to setting up TLS with the goal of not having to think about it.

I fully expect a wave of security concerns coming back, but my question remains.

Please and thank you.

5

Hi, Marco,

thanks very much for your valuable feedback, this is really helpful. In fact, we’re currently working on some improvements for the upcoming SG6 release, to make life easier for users that are not deep into TLS. Right, the samples, scripts and docs are probably geared more towards DevOps people who know TLS in and out than towards developers who just want to quickly test our features.

There are some improvements around TLS coming with Search Guard 6. In particular, we will extend the example PKI scripts to be more of a real tool rather than just examples, as you suggested. It will work similar to the online TLS generator, you can specify all required information regarding root CA, hostnames etc. in a YAML or JSON file and it will generate all artifacts for you.

The initial setup to get a PoC up and running will also be easier. After installation, you just run a script which will generate the certificates, add the config entries to ealsticsearch.yml and intialize the SG index automatically. This will basically be all that you need to do to set up a PoC.

Is that something that would have helped in your situation?

We also have a short section in the docs regarding TLS:

I guess its too brief and hidden quite well under all the other docs :wink:

I’ve got two other questions - if you were tasked to test the SG features to see if they fit your companies needs, did you come across the Search Guard Bundle? This is a pre-configured SG installation that runs out of the box, and was created especially for setting up a PoC. Would that have been useful?

Second, if you have time, it would be great if you could use the TLS generator service once and check if the provided installation instructions in the README are clear to you.

We will also release an SG6 beta soon, so if you like you can also give it a test drive and let us know if things have improved in your opinion.

So, thanks very much again for your great input, this really helps us to make Search Guard a better product!

Jochen

···

On Friday, September 29, 2017 at 5:56:37 PM UTC+2, mcostantini@np6.com wrote:

Thanks for the great reply. I’ll reply too! I hope my perspective and journey with setting up yields some good things for you guys (although I’m sure you’ve seen it all 100x before). Also, thanks for the great product.

The first thing that should be said is that I effectively have no experience with the inner workings of TLS. I’ve been able to use TLS for HTTP on many projects, but for me, that’s been as easy as requesting certs, and having a hosting provider install them. I am a developer, and I should know this (now is the time!), but as of yet, the inner workings of TLS have escaped me.

Now, I’ve been charged with doing a feasibility test of the authorization features of SearchGuard within our private network. I hope you can see the conflict here right away. We haven’t committed to SG yet, we just wanted to try it out to see what auth looks like with SG.

I’m now going to respond to some of the points you made:

  • I understand that you’ve made TLS mandatory and I understand why. I agree that private networks do not solve the problem.
  • My understanding of TLS was so insufficient that I was not even confident using the online generator. I know it’s dead simple, but when I started, it was all a different language to me.

Back to me:
You guys are the experts on security and your product. However, the inability to temporarily turn off TLS for the purpose of my feasibility test would have saved SO MUCH TIME. That being said, I see an alternative: educate your users on TLS from the perspective of ES and SG. Sure, it may be overkill, but it’s definitely an inclusive move, and after having a few external, personal conversations about this, I have a feeling there are more noobs like me than you think.

I’m taking another look at the online generator. It is mostly what I needed. This plus some entry-level, domain specific docs on TLS with SG and ES. If they exist and I’ve missed them, or skipped them at the time, point them out to me please. I think I’m a good candidate for saying if it is “nooby” enough. :smiley:

Many thanks,

Marco.

On Friday, September 29, 2017 at 2:55:32 PM UTC+2, Jochen Kressin wrote:

Mi Marco,

thanks for your feedback. Regarding TLS being mandatory - well, we’re a “security first” company and have strong opinions on that topic of course.

Search Guard always required TLS on transport level, and even though we got a lot of requests to make it optional, we always stuck to our initial decision. Reason: You will never be able to implement proper security without encrypting the data in transit. It seems that with the release of X-Pack 6 Elastic (finally!) follows our path, since TLS on transport will be mandatory also in X-Pack Security. Better late than never!

A private network alone definitely will not help here, since according to various security studies (e.g. from IBM), more than 50% of the attacks come from the inside, not the outside. That’s why all compliance standards like GDRP, HIPAA, PCI etc. require encryption for data in transit, and sometimes also at rest. The future of Enterprise Security will definitely be “zero trust networks” (e.g. https://cloud.google.com/beyondcorp/) and the least you can do is to encrypt traffic. In my opinion, the days where you could rely on private networks, VPNs, firewalls etc. are definitely over. See for example the OneLogin breaches.

Security in general and TLS in particular is definitely not an easy topic, and if someone tells you his or her security solution just works out of the box - don’t trust them. It just doesn’t. One needs to familiarize with the concepts behind any security solution to make sure it does what it’s supposed to do. We think there is no shortcut to that. For example, in order to execute sgadmin you need to provide a client certificate. This was a deliberate decision because the other option would be to provide a default password or generate a random password upon installation. Default passwords are a no-go, and randomly generated passwords are also insecure. That’s why we took the certificate based approach, even if it is a bit harder to understand than just typing admin/admin :wink:

But having said all that :wink: …

I’m curious about the hurdles you faced when creating the certificates. I always thought that creating certificates for Search Guard is not harder than, say, generating a certificate for a web server. You need to generate a CSR in both cases and submit it to a CA (be it external or your internal PKI). You get back certificates, e.g. in PEM format, and need to configure the cert and the key on the server, which is ES/SG in this case. Also with a web server certificate, you need to make sure to provide the correct information in the CSR, for example, the correct hostname.

We can definitely extend the example scripts, but they surely require Java and OpenSSL installed on the machine where you execute them. For users that cannot use them, we provide the TLS certificate generator service on our website. For companies that have a PKI infrastructure in place, TLS is usually not a problem, and we see more and more companies moving away from traditional user/password based approaches, towards certificates only infrastructure.

So I really like to learn more about the specific issues you faced and the infrastructure you’re working with, so we can improve the whole TLS topic further. You can also take this conversation private if you like by dropping me an email: jkre...@floragunn.com

Thanks for your feedback!

On Friday, September 29, 2017 at 2:29:13 PM UTC+2, mcost...@np6.com wrote:

For my case, I just needed to make sure the SAN in the node certs was accurate. So, solved.

I still recommend a small education on TLS. I know it’s not your product but it is SO closely tied to it.

In lieu of that, I recommend wrapping up the ‘example’ script bundle into something more practical and non example-like. That’s what I ended up doing in the end: dropping my node info straight into the example scripts.

Thanks,

Marco.

On Thursday, September 28, 2017 at 6:17:46 PM UTC+2, mcost...@np6.com wrote:

We don’t want transport TLS. Our whole cluster exists in a private network. Regardless, we try to get it working as its required. Today, I am getting this

Caused by: java.security.cert.CertificateException: No subject alternative DNS name matching poc-profiles-es-01 found.

``

It’s not a sudden error. I’m deploying to a new cluster. After some reading, I put these properties in elasticsearch.yml
searchguard.ssl.transport.enforce_hostname_verification: false

searchguard.ssl.transport.resolve_hostname: false

``

The error remains. I think many people face this same issue. Whether they need TLS or not, I think many people will want to test SG with TLS not being a variable, at some stage.

Question: Without resorting to using the demo scripts, what would be the minimal path to setting up TLS with the goal of not having to think about it.

I fully expect a wave of security concerns coming back, but my question remains.

Please and thank you.

6

Hi Jochen,
It sounds like SG6 will have some great improvements in this area. Great!

To answer some of your questions:

  • I only became aware of the SearchGuard bundle in the past few days. I cannot conclusively say that it was the first time, though. I may have seen it, dismissed it (for some ungodly reason) at the time, and have forgotten about it. in any case, it was not on my radar until recently. i DO remember trying to find such a dockerized bundle, not being able to, and resorting to learning how to deploy it. was the bundle made available only recently?

  • When we last spoke (wrote), I immediately tried out the online certificate generator. I got the message saying the files are on their way, but sadly, I did not receive the files. Maybe I entered my email incorrectly, but I doubt it. Give it a quick test. Could be a client to keyboard interface error. :smiley: Maybe you chould check the history for this very email (mcostantini@np6.com). I have no need for the actual files, I just wanted to see the process for feedback purposes.

Thanks for getting back to me. In all cases, your team has demonstrated it’s commitment to quality of service and of its products.

M

···

On Tuesday, October 3, 2017 at 9:17:08 AM UTC+2, Jochen Kressin wrote:

Hi, Marco,

thanks very much for your valuable feedback, this is really helpful. In fact, we’re currently working on some improvements for the upcoming SG6 release, to make life easier for users that are not deep into TLS. Right, the samples, scripts and docs are probably geared more towards DevOps people who know TLS in and out than towards developers who just want to quickly test our features.

There are some improvements around TLS coming with Search Guard 6. In particular, we will extend the example PKI scripts to be more of a real tool rather than just examples, as you suggested. It will work similar to the online TLS generator, you can specify all required information regarding root CA, hostnames etc. in a YAML or JSON file and it will generate all artifacts for you.

The initial setup to get a PoC up and running will also be easier. After installation, you just run a script which will generate the certificates, add the config entries to ealsticsearch.yml and intialize the SG index automatically. This will basically be all that you need to do to set up a PoC.

Is that something that would have helped in your situation?

We also have a short section in the docs regarding TLS:

http://floragunncom.github.io/search-guard-docs/addendum_c_tls_primer.html

I guess its too brief and hidden quite well under all the other docs :wink:

I’ve got two other questions - if you were tasked to test the SG features to see if they fit your companies needs, did you come across the Search Guard Bundle? This is a pre-configured SG installation that runs out of the box, and was created especially for setting up a PoC. Would that have been useful?

https://github.com/floragunncom/search-guard/wiki/Search-Guard-Bundle

Second, if you have time, it would be great if you could use the TLS generator service once and check if the provided installation instructions in the README are clear to you.

We will also release an SG6 beta soon, so if you like you can also give it a test drive and let us know if things have improved in your opinion.

So, thanks very much again for your great input, this really helps us to make Search Guard a better product!

Jochen

On Friday, September 29, 2017 at 5:56:37 PM UTC+2, mcost...@np6.com wrote:

Thanks for the great reply. I’ll reply too! I hope my perspective and journey with setting up yields some good things for you guys (although I’m sure you’ve seen it all 100x before). Also, thanks for the great product.

The first thing that should be said is that I effectively have no experience with the inner workings of TLS. I’ve been able to use TLS for HTTP on many projects, but for me, that’s been as easy as requesting certs, and having a hosting provider install them. I am a developer, and I should know this (now is the time!), but as of yet, the inner workings of TLS have escaped me.

Now, I’ve been charged with doing a feasibility test of the authorization features of SearchGuard within our private network. I hope you can see the conflict here right away. We haven’t committed to SG yet, we just wanted to try it out to see what auth looks like with SG.

I’m now going to respond to some of the points you made:

  • I understand that you’ve made TLS mandatory and I understand why. I agree that private networks do not solve the problem.
  • My understanding of TLS was so insufficient that I was not even confident using the online generator. I know it’s dead simple, but when I started, it was all a different language to me.

Back to me:
You guys are the experts on security and your product. However, the inability to temporarily turn off TLS for the purpose of my feasibility test would have saved SO MUCH TIME. That being said, I see an alternative: educate your users on TLS from the perspective of ES and SG. Sure, it may be overkill, but it’s definitely an inclusive move, and after having a few external, personal conversations about this, I have a feeling there are more noobs like me than you think.

I’m taking another look at the online generator. It is mostly what I needed. This plus some entry-level, domain specific docs on TLS with SG and ES. If they exist and I’ve missed them, or skipped them at the time, point them out to me please. I think I’m a good candidate for saying if it is “nooby” enough. :smiley:

Many thanks,

Marco.

On Friday, September 29, 2017 at 2:55:32 PM UTC+2, Jochen Kressin wrote:

Mi Marco,

thanks for your feedback. Regarding TLS being mandatory - well, we’re a “security first” company and have strong opinions on that topic of course.

Search Guard always required TLS on transport level, and even though we got a lot of requests to make it optional, we always stuck to our initial decision. Reason: You will never be able to implement proper security without encrypting the data in transit. It seems that with the release of X-Pack 6 Elastic (finally!) follows our path, since TLS on transport will be mandatory also in X-Pack Security. Better late than never!

A private network alone definitely will not help here, since according to various security studies (e.g. from IBM), more than 50% of the attacks come from the inside, not the outside. That’s why all compliance standards like GDRP, HIPAA, PCI etc. require encryption for data in transit, and sometimes also at rest. The future of Enterprise Security will definitely be “zero trust networks” (e.g. https://cloud.google.com/beyondcorp/) and the least you can do is to encrypt traffic. In my opinion, the days where you could rely on private networks, VPNs, firewalls etc. are definitely over. See for example the OneLogin breaches.

Security in general and TLS in particular is definitely not an easy topic, and if someone tells you his or her security solution just works out of the box - don’t trust them. It just doesn’t. One needs to familiarize with the concepts behind any security solution to make sure it does what it’s supposed to do. We think there is no shortcut to that. For example, in order to execute sgadmin you need to provide a client certificate. This was a deliberate decision because the other option would be to provide a default password or generate a random password upon installation. Default passwords are a no-go, and randomly generated passwords are also insecure. That’s why we took the certificate based approach, even if it is a bit harder to understand than just typing admin/admin :wink:

But having said all that :wink: …

I’m curious about the hurdles you faced when creating the certificates. I always thought that creating certificates for Search Guard is not harder than, say, generating a certificate for a web server. You need to generate a CSR in both cases and submit it to a CA (be it external or your internal PKI). You get back certificates, e.g. in PEM format, and need to configure the cert and the key on the server, which is ES/SG in this case. Also with a web server certificate, you need to make sure to provide the correct information in the CSR, for example, the correct hostname.

We can definitely extend the example scripts, but they surely require Java and OpenSSL installed on the machine where you execute them. For users that cannot use them, we provide the TLS certificate generator service on our website. For companies that have a PKI infrastructure in place, TLS is usually not a problem, and we see more and more companies moving away from traditional user/password based approaches, towards certificates only infrastructure.

So I really like to learn more about the specific issues you faced and the infrastructure you’re working with, so we can improve the whole TLS topic further. You can also take this conversation private if you like by dropping me an email: jkre...@floragunn.com

Thanks for your feedback!

On Friday, September 29, 2017 at 2:29:13 PM UTC+2, mcost...@np6.com wrote:

For my case, I just needed to make sure the SAN in the node certs was accurate. So, solved.

I still recommend a small education on TLS. I know it’s not your product but it is SO closely tied to it.

In lieu of that, I recommend wrapping up the ‘example’ script bundle into something more practical and non example-like. That’s what I ended up doing in the end: dropping my node info straight into the example scripts.

Thanks,

Marco.

On Thursday, September 28, 2017 at 6:17:46 PM UTC+2, mcost...@np6.com wrote:

We don’t want transport TLS. Our whole cluster exists in a private network. Regardless, we try to get it working as its required. Today, I am getting this

Caused by: java.security.cert.CertificateException: No subject alternative DNS name matching poc-profiles-es-01 found.

``

It’s not a sudden error. I’m deploying to a new cluster. After some reading, I put these properties in elasticsearch.yml
searchguard.ssl.transport.enforce_hostname_verification: false

searchguard.ssl.transport.resolve_hostname: false

``

The error remains. I think many people face this same issue. Whether they need TLS or not, I think many people will want to test SG with TLS not being a variable, at some stage.

Question: Without resorting to using the demo scripts, what would be the minimal path to setting up TLS with the goal of not having to think about it.

I fully expect a wave of security concerns coming back, but my question remains.

Please and thank you.