SSL config settings confusion

[Marko Božiković]

Hi all,


I'm looking for some clarity about the
searchguard.ssl.transport.pemtrustedcas_filepath and
searchguard.ssl.http.pemtrustedcas_filepath settings. What are they actually
used for and how?

We are on ES 5.6.7 and SG 5.6.7-19

For internal testing, we provision both node and sgadmin certificates using
Hashicorp's Vault (using their pki secrets backend). The Vault is configured
to use our internal CA and intermediate certificates to generate new
certificates. So, we end up with out pair of cert files (sgadmin and node), a
pair of PKCS8 key files and a single ca.pem file, which only needs to contain
our CA root cert.

Our internal CA Root cert is also added to the server's trusted certificates
(linked to /etc/ssl/certs)

For production, we still use our Vault server to provision sgadmin certs, but
use "proper" node certificates (from Comodo in this particular scenario) and
this is where the confusion kicks in.

It would appear that in order to get the sgadmin.sh to work, the ca.pem file
needs to contain our CA root cert and any cert from our node "proper" cert's
chain (I tried putting in the node cert itself or the next intermediate cert).

On the other hand, whatever I put in ca.pem (I tried putting only our root CA
cert), the node will happily restart and if I browse to, say
https://my.server.com:9200/_nodes, the browser will be happy with the Comodo's
SSL cert chain, which makes it look like the
pemtrustedcas_filepath file has no effect on the nodes.

What am I missing here?

Thank you,

--
Marko Bozikovic
Senior Developer
Symplectic
Email: bo...@symplectic.co.uk

[Jochen Kressin]

Hi,

I'm not 100% sure I understand the use case completely, but I will give it a shot ...

First, sgadmin talks to Search Guard on the transport layer using a TransportClient. So for sgadmin, only the searchguard.ssl.transport.* settings are relevant.

For TLS, it actually does not matter where you place the intermediate certificates. The only relevant thing is that the complete chain of certificates is present and can be validated. For example, you can place the intermediates in your root_ca.pem, and then only use the admin certificate (without intermediates) in the sgadmin calls. Or you do it the other way round, just place the actual root CA in root_ca.pem, but then you need to send the admin certificate plus all intermediates in the sgadmin call. It is somewhat a matter of taste, but the latter approach is more commonly used.

The pemtrustedcas_filepath settings are indeed used to provide Search Guard with the root CA for validation. I think the confusion comes from how certificates are validated on REST layer / with a browser.

For inter-node communication, means the transport layer, Search Guard is responsible for validating any node certificate against the configured root CA, configured in searchguard .ssl.transport.pemtrustedcas_filepath.

Now if you use a browser and connect via HTTPS, it is actually the browser that validates the certificate against it's list of well-known root CAs. Since you use Comodo this will just work out of the box, since the browser trusts the Comodo root CA, regardless of your searchguard.ssl.http.pemtrustedcas_filepath settings.  

So when does the searchguard.ssl.http.pemtrustedcas_filepath come into play? This is used when you want to use TLS certificates for client authentication. For example, if you use a TLS certificate to use the Search Guard REST API. In this case you would send the client certificate, e.g. with curl, and SG will validate it against the configured searchguard.ssl.http.pemtrustedcas_filepath root and/or intermediate certificate(s).

Hope this helps clarifying your question!

[Marko Božiković]

Hi Jochen,

Thank you very much for a detailed explanation. I was struggling with this at 1 a.m., so it was partially a case of declined mental capacity - the first thing that occurred to me the next morning was that sgadmin uses cert-based authentication, so both sgadmin and SearchGuard must be able to validate each other's certs.

Thank you once again!
Marko

--
You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com.
To post to this group, send email to search...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/c227fc6a-d2e3-4fa3-97ad-1824682bdf85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.