Custom name for http certificate in elastic cluster

Elastic Security
1

Hi elastic engineers,
I have a few questions in regards to the certificate generation process

[1] Is it allowed to use custom name for http certificate instead of default http.p12 ?

The elasticsearch-certutil does allow to generate the certificate (encrypt communication between nodes in a cluster) with custom name like elastic-certificates-TEST.p12 instead of default name elastic-certificates.p12
Running utility "bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12" prompts to enter the desired output file name and I can use/reference this name elastic-certificates-TEST.p12 in elasticsearch.yml

But generating the http.p12 certificate does not provide this capability and running utility "bin/elasticsearch-certutil http" will always generate *.zip file which contains the http certificate with default name http.p12
I renamed default file name http.p12, after it has been generated, to new custom name like http-TEST.p12, referenced this custom name in elasticserch.yml and was able to successfully run the 2 servers/4 nodes cluster.

Also, I generated http-TEST.crt from http-TEST.p12 as follows
openssl pks12 -in http-TEST.p12 -out http-TEST.crt -cacerts -nokeys
and was able to successfully run CURL REST API commands and java app client by referencing this custom name http-TEST.crt

Just rephrasing my original question as follows
Is this renaming of default names http.p12/http.crt to custom names like http-TEST.p12/http-TEST.crt allowed and will Not change the normal behavior of elastic cluster ?
I didn't find any references about this possibility/capability in elastic docs
Renaming default certificate names http.p12/http.crt to custom names would be helpful when maintaining certificates for different environments, like http-QA.p12/http-QA.crt, http-XAT.p12/http-XAT.crt, http-PROD.p12/http-PROD.crt

Another question is in regards to certificate generation and elastic cluster running with different java versions
[2] Is it possible/allowed to generate certificates with one particular version, like jdk1.8.0_65 and run on the elastic cluster with another higher version, like jdk1.8.0_180 or java 11 ?

Thanks in advance

2

Yes. Filenames are just filenames and since we don't hardcode anything in our codebase, you can name the files however you want, and reference those in the configuration.

Yes it is possible. The biggest the difference in versions, the more risk you have that something significant has changed and caused an incompatibility, so I'd suggest you stick to a JDK version for generating the key/certificates as close to what you'd be using in production

3

Thank you Ioannis for the confirmation

4

Is there any way to protect http.crt with password and use it with CURL ?

Converting http.p12 into http.crt via openssl creates passwordless http.crt
openssl pks12 -in http.p12 -out http.crt -cacerts -nokeys

It would be nice to have password protected http.crt and when running curl
curl --cacert http.crt -u user:password -XGET 'https://ip:port/_cat/nodes?v'
provide a password when prompted or any other way
Thanks in advance

5

Why would you want to password protect a certificate file in general? X509 Certificates are basically binding of a subject ( think a DNS name, or an IP address ) to a public key. This key is not meant to be secret.

The certificate you refer to above is the certificate of the Certificate Authority and you are basically telling curl that it should trust the server's certificate if it is signed by that Certificate Authority. There is no reason to password protect that file.

6

I'm using password-protected PKCS#12 certificates elastic-certificates.p12, http.p12 and elasticsearch.keystore, deployed on the cluster's nodes. Multi-nodes cluster works well as it should.

Converting password-protected http.p12 into http.crt via openssl produces passwordless http.crt.
The reason to protect http.crt with password is to being able to restrict access to the cluster via CURL and certificate for some users only for whom the password of the certificate will be provided and can be changed if needed.

If http.crt can not be used for such a purpose, maybe there is some other http password-protected certificate format, which can be used to access the cluster via CURL or some other way to achieve this functionality ?

7

It is not possible to achieve what you're looking for by controlling access to http.crt

The command you are running:

curl --cacert http.crt -u user:password -XGET 'https://ip:port/_cat/nodes?v'

Could easily be replace with

curl --insecure -u user:password -XGET 'https://ip:port/_cat/nodes?v'

Which would instruct curl not to perform certificate verification, and would bypass whatever protection you had around the http.crt file.

Or, because of the nature of how SSL/TLS works, it is possible to download http.crt from the Elasticsearch node itself using a tool like openssl s_client.

The http.crt file simply can't be used to prevent unauthorised users from accessing your nodes.

What security protection are you trying to implement here. You already have password protection on your node:

curl --cacert http.crt -u user:password -XGET 'https://ip:port/_cat/nodes?v'

You can add further protections if you wish, but if what you want is

some users only for whom the password [of the certificate] will be provided and can be changed if needed

then user authentication is what you want. Each authorised user is given a username & password, and as the admin you can change their password or revoke their access.

Alternatively, if your main priority is to

restrict access to the cluster via CURL and certificate

Then you want to look into client certificates (mTLS) which is supported on Elasticsearch by setting xpack.security.http.ssl.client_authentication: required (but you need additional configuration as well - if all you do it turn that on it will just lock everyone out).

However, that is much harder to revoke. You would need to reconfigure the server to use a new trust chain anytime you wanted to revoke access to a certificate.

8

I maintain password-protected PKCS#12 certificates elastic-certificates.p12, http.p12 on the nodes.
Can you please provide the full command openssl s_client to download the http.crt ?

Thanks a lot Tim for your attention, explanation and help.

9

That's not an entirely accurate description of what's going on. A PKCS#12 file is a keystore. It is designed to store private keys, so it has password protection. A PEM certificate file does not support password protection because it is not a private key, it is a public certificate.

Can you please provide the full command openssl s_client to download the http.crt ?

openssl s_client -connect localhost:9200 -showcerts
10

Thank you Tim for sharing your knowledge and experience

11

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.