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\.