PKCS #12 Certificates

[kobelb]

Customers are requesting PKCS #12 certificates in addition PEM certificates. We'll want to be able to add these for the Elasticsearch SSL connections, as well as the Kibana HTTPS server.

The following Kibana settings allow PEM encoded certificates to be specified:

• elasticsearch.ssl.certificate
• elasticsearch.ssl.key
• elasticsearch.ssl.certificateAuthorities
• server.ssl.certificate
• server.ssl.key
• server.ssl.certificateAuthorities

[jportner]

Looking at this now, seems doable with the pem module's readPkcs12 method -- that will allow us to extract the CA cert, instance cert, and instance private key separately.

The only caveat that I can see so far is that this module depends on OpenSSL being installed. It appears that this will work with Windows, but may require an environment variable set to point to the OpenSSL binary. I assume this will be acceptable (with appropriate error messages of course), as reading PKCS12 certificates will be an optional added feature that will not affect vanilla installs.

[kobelb]

I assume this will be acceptable (with appropriate error messages of course), as reading PKCS12 certificates will be an optional added feature that will not affect vanilla installs.

It's preferable for us to not have to depend on a shared library... we've historically run into a lot of issues with Reporting needing limited shared libraries. Have you already looked into and ruled out https://www.npmjs.com/package/node-forge as a potential option? NodeJS also has a bundled version of OpenSSL that they use internally, when I looked last I wasn't able to figure out how we could call it though.

[legrego]

NodeJS also has a bundled version of OpenSSL that they use internally, when I looked last I wasn't able to figure out how we could call it though.

I was just trying to figure this out. As far as I can tell, OpenSSL is statically linked into the Node.js executable. I think, if we want to take advantage of this, that we'd need to create/use a native module to communicate with OpenSSL outside of what the Node.js runtime provides.

[jportner]

NodeJS also has a bundled version of OpenSSL that they use internally, when I looked last I wasn't able to figure out how we could call it though.

I was just trying to figure this out. As far as I can tell, OpenSSL is statically linked into the Node.js executable. I think, if we want to take advantage of this, that we'd need to create/use a native module to communicate with OpenSSL outside of what the Node.js runtime provides.

Yes, I believe that's correct.

node-forge sounds like it might be a better approach, I'll take a look at that.

[jportner]

@kobelb node-forge is working, great suggestion! We'll need to add plenty of tests to handle the different variations of P12 keystores we might encounter, but we would need to do that anyway.

[jportner]

We have a lot of flexibility in terms of what configuration options we can support. Jotting down my thoughts here so anyone can comment with feedback.

Supporting a trust store

A "key store" may contain an end-entity certificate with its private key to be used for authentication, and optionally a Certificate Authority (CA) chain to establish trust.

A "trust store" is simply a key store that is only used for trust. I.e., it may contain a CA chain, but no end-entity certificate or private key.

Since our new approach handles P12 key stores in a different way -- by reading them and parsing out the key/certs -- we can support a separate trust store. This is what Elasticsearch provides with a separate ssl.keystore.path and ssl.truststore.path. The reverted PR (#17261) contained some discussion on this subject, but it sounds like that was nixed because Node couldn't handle a separate trust store with that approach.

Key store password(s)

Elasticsearch allows for a separate keystore.password and keystore.key_password -- this is because it supports different types of key stores, not just PKCS#12. We don't need to support this, since PKCS#12 key stores typically only allow for a single password to be used for both the private key and the key store itself. While it's technically possible to have different passwords for these, tools like Keytool and OpenSSL will not allow you to create a key store in this manner.

On another note, upon investigating I've determined that valid PKCS#12 key stores may come in one of the following configurations:

1. Password
2. Empty password (can be generated with OpenSSL)
3. No password (can be generated with MacOS Keychain)

With that in mind, we should support (and test for) all three cases.

Separate certificate authorities

Some users may have a key store with their end-entity certificate and private key, and they may also have one or more separate files with PEM-formatted certificates for the CA chain. To that end, I think we should support reading CA certificates from multiple sources and combining them.

TL;DR

I am currently aiming to add the following configuration options for Kibana:

• elasticsearch.ssl.keystore.path
• elasticsearch.ssl.keystore.password
• elasticsearch.ssl.truststore.path
• elasticsearch.ssl.truststore.password
• server.ssl.keystore.path
• server.ssl.keystore.password
• server.ssl.truststore.path
• server.ssl.truststore.password

Any other feedback would be appreciated!