SSL config settings confusion

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: bozho@symplectic.co.uk

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!

···

On Wednesday, September 12, 2018 at 11:31:02 AM UTC+2, Marko BoŇĺikovińá wrote:

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: bozho@symplectic.co.uk

1 Like

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

···

On 17/09/2018 15:48, Jochen Kressin wrote:

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!

On Wednesday, September 12, 2018 at 11:31:02 AM UTC+2, Marko BoŇĺikovińá wrote:

    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: bozho@symplectic.co.uk <mailto:bozho@symplectic.co.uk>

--
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+unsubscribe@googlegroups.com
<mailto:search-guard+unsubscribe@googlegroups.com>.
To post to this group, send email to search-guard@googlegroups.com
<mailto:search-guard@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
<https://groups.google.com/d/msgid/search-guard/c227fc6a-d2e3-4fa3-97ad-1824682bdf85%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

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