Hi all,
I am looking into automating SSL certificate provisioning for our ES+SG deployments, both in test (internal environment) and production and I have some questions.
We plan to use an internal CA for our test ES deployment (as well as other internal services), where we would have a simple chain: root cert → intermediate cert → ES node certs. For testing purposes, these are currently being created manually, but the plan is to use the intermediate certificate with Hashicorp’s Vault to automate issuing of certificates.
For production, we plan to use Let’s Encrypt certs (and automate renewal).
Through some experimentation, I was able to generate node certificates that SG is happy with (the critical bit was setting key usage to both server and client auth).
I am now trying to figure out how to create client certs to use with sgadmin. I am able to generate client certs using the same OpenSSL configuration used for node certs (setting CN to something like ‘admin’).
At first, I tried using demo client certs (kirk, sgadmin), but sgadmin would fail with an “unknown certificate” error. Am I right to assume that client certs need to share the same certificate chain as node certs?
If that is so, what’s the best practice for production and getting client certs?
Thank you,
···
–
Marko
Yes, client/admin certificates should share the same root CA as the node certificates. However, this is not strictly required since you can also have multiple root CAs configured. You either import them to the keystore (if you use JKS) or add them all to your root CA PEM file.
Client/admin certificates are simple client certificates with no special requirements regarding EKU, OID etc.
Just be aware that using Let’s Encrypt alone will not work! You can generate server certificates with it, but AFAIK there is no way to generate simple client certificates. But you need at least two certificates for a SG installation: One node and one admin certificate. Let me know if this has changed with Let’s Encrypt, or how you are trying to implement it. Using Let’s Encrypt certificates only for HTTPS and use self-signed certificates for the nodes is of course perfectly possible.
···
On Tuesday, July 3, 2018 at 12:55:01 PM UTC+2, Marko Božiković wrote:
Hi all,
I am looking into automating SSL certificate provisioning for our ES+SG deployments, both in test (internal environment) and production and I have some questions.
We plan to use an internal CA for our test ES deployment (as well as other internal services), where we would have a simple chain: root cert → intermediate cert → ES node certs. For testing purposes, these are currently being created manually, but the plan is to use the intermediate certificate with Hashicorp’s Vault to automate issuing of certificates.
For production, we plan to use Let’s Encrypt certs (and automate renewal).
Through some experimentation, I was able to generate node certificates that SG is happy with (the critical bit was setting key usage to both server and client auth).
I am now trying to figure out how to create client certs to use with sgadmin. I am able to generate client certs using the same OpenSSL configuration used for node certs (setting CN to something like ‘admin’).
At first, I tried using demo client certs (kirk, sgadmin), but sgadmin would fail with an “unknown certificate” error. Am I right to assume that client certs need to share the same certificate chain as node certs?
If that is so, what’s the best practice for production and getting client certs?
Thank you,
Marko
Ah, brilliant! After reading the documentation a bit more carefully (doh!), I
see that I can bundle multiple root CAs into my pemtrustedcas_filepath file.
I'll try testing with two root certs tomorrow.
One more question about using Let's Encrypt certs as node certs, if you know:
is it possible to set OID for node certificate validation?
Thank you,
···
On 04/07/2018 21:06, Jochen Kressin wrote:
Yes, client/admin certificates should share the same root CA as the node
certificates. However, this is not strictly required since you can also have
multiple root CAs configured. You either import them to the keystore (if you
use JKS) or add them all to your root CA PEM file.
Client/admin certificates are simple client certificates with no special
requirements regarding EKU, OID etc.
Just be aware that using Let's Encrypt alone will not work! You can generate
server certificates with it, but AFAIK there is no way to generate simple
client certificates. But you need at least two certificates for a SG
installation: One node and one admin certificate. Let me know if this has
changed with Let's Encrypt, or how you are trying to implement it. Using
Let's Encrypt certificates only for HTTPS and use self-signed certificates
for the nodes is of course perfectly possible.
--
Marko Bozikovic
Senior Developer
Symplectic
Email: bozho@symplectic.co.uk
AFAIK no, you cannot embed OIDs in Let’s Encrpyt certificates. But you can always list the DNs of the certificates in elasticsearch.yml instead of using an OID. Both ways are equivalent. But note that an OID/listing the DNs is only required for node certificates on transport layer. For HTTPS it is not required.
···
On Thursday, July 5, 2018 at 1:42:18 AM UTC+2, Marko Božiković wrote:
On 04/07/2018 21:06, Jochen Kressin wrote:
Yes, client/admin certificates should share the same root CA as the node
certificates. However, this is not strictly required since you can also have
multiple root CAs configured. You either import them to the keystore (if you
use JKS) or add them all to your root CA PEM file.
Client/admin certificates are simple client certificates with no special
requirements regarding EKU, OID etc.
Just be aware that using Let’s Encrypt alone will not work! You can generate
server certificates with it, but AFAIK there is no way to generate simple
client certificates. But you need at least two certificates for a SG
installation: One node and one admin certificate. Let me know if this has
changed with Let’s Encrypt, or how you are trying to implement it. Using
Let’s Encrypt certificates only for HTTPS and use self-signed certificates
for the nodes is of course perfectly possible.
Ah, brilliant! After reading the documentation a bit more carefully (doh!), I
see that I can bundle multiple root CAs into my pemtrustedcas_filepath file.
I’ll try testing with two root certs tomorrow.
One more question about using Let’s Encrypt certs as node certs, if you know:
is it possible to set OID for node certificate validation?
Thank you,
–
Marko Bozikovic
Senior Developer
Symplectic
Email: bozho@symplectic.co.uk