# Custom name for http certificate in elastic cluster

**URL:** <https://discuss.elastic.co/t/custom-name-for-http-certificate-in-elastic-cluster/267009>\
**Category:** Elastic Security\
**Tags:** elastic-stack-security\
**Created:** [March 12, 2021, 12:05am UTC](https://discuss.elastic.co/t/custom-name-for-http-certificate-in-elastic-cluster/267009 "2021-03-12T00:05:39Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![dzyubanv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dzyubanv/32/24110_2.png) [@dzyubanv](https://discuss.elastic.co/u/dzyubanv)\
**Post date:** [March 12, 2021, 12:05am UTC](https://discuss.elastic.co/t/custom-name-for-http-certificate-in-elastic-cluster/267009/1 "2021-03-12T00:05:39Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)\
**Post date:** [March 12, 2021, 7:11am UTC](https://discuss.elastic.co/t/custom-name-for-http-certificate-in-elastic-cluster/267009/2 "2021-03-12T07:11:34Z")

</div>

> [@dzyubanv](#):
>
> 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 ?

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.

> [@dzyubanv](#):
>
> [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 ?

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

---

<div class="post-metadata">

**Author:** ![dzyubanv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dzyubanv/32/24110_2.png) [@dzyubanv](https://discuss.elastic.co/u/dzyubanv)\
**Post date:** [March 13, 2021, 8:21pm UTC](https://discuss.elastic.co/t/custom-name-for-http-certificate-in-elastic-cluster/267009/3 "2021-03-13T20:21:46Z")

</div>

Thank you Ioannis for the confirmation

---

<div class="post-metadata">

**Author:** ![dzyubanv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dzyubanv/32/24110_2.png) [@dzyubanv](https://discuss.elastic.co/u/dzyubanv)\
**Post date:** [March 16, 2021, 1:47pm UTC](https://discuss.elastic.co/t/custom-name-for-http-certificate-in-elastic-cluster/267009/4 "2021-03-16T13:47:20Z")

</div>

**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

---

<div class="post-metadata">

**Author:** ![ikakavas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ikakavas/32/34430_2.png) [@ikakavas](https://discuss.elastic.co/u/ikakavas)\
**Post date:** [March 16, 2021, 6:12pm UTC](https://discuss.elastic.co/t/custom-name-for-http-certificate-in-elastic-cluster/267009/5 "2021-03-16T18:12:32Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dzyubanv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dzyubanv/32/24110_2.png) [@dzyubanv](https://discuss.elastic.co/u/dzyubanv)\
**Post date:** [March 16, 2021, 10:10pm UTC](https://discuss.elastic.co/t/custom-name-for-http-certificate-in-elastic-cluster/267009/6 "2021-03-16T22:10:35Z")

</div>

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 ?**

---

<div class="post-metadata">

**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\
**Post date:** [March 17, 2021, 4:16am UTC](https://discuss.elastic.co/t/custom-name-for-http-certificate-in-elastic-cluster/267009/7 "2021-03-17T04:16:14Z")

</div>

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

The command you are running:

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

```

Could easily be replace with

```auto
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.

> [@dzyubanv](#):
>
> **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.

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](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.

---

<div class="post-metadata">

**Author:** ![dzyubanv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dzyubanv/32/24110_2.png) [@dzyubanv](https://discuss.elastic.co/u/dzyubanv)\
**Post date:** [March 18, 2021, 12:41am UTC](https://discuss.elastic.co/t/custom-name-for-http-certificate-in-elastic-cluster/267009/8 "2021-03-18T00:41:26Z")

</div>

> [@TimV](#):
>
> 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`

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.

---

<div class="post-metadata">

**Author:** ![TimV](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/timv/32/13162_2.png) [@TimV](https://discuss.elastic.co/u/TimV)\
**Post date:** [March 18, 2021, 2:27am UTC](https://discuss.elastic.co/t/custom-name-for-http-certificate-in-elastic-cluster/267009/9 "2021-03-18T02:27:04Z")

</div>

> [@dzyubanv](#):
>
> I maintain password-protected PKCS#12 certificates elastic-certificates.p12, http.p12 on the nodes.

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 ?

```auto
openssl s_client -connect localhost:9200 -showcerts

```

---

<div class="post-metadata">

**Author:** ![dzyubanv](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dzyubanv/32/24110_2.png) [@dzyubanv](https://discuss.elastic.co/u/dzyubanv)\
**Post date:** [March 19, 2021, 12:31am UTC](https://discuss.elastic.co/t/custom-name-for-http-certificate-in-elastic-cluster/267009/10 "2021-03-19T00:31:19Z")

</div>

Thank you Tim for sharing your knowledge and experience

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [April 16, 2021, 12:32am UTC](https://discuss.elastic.co/t/custom-name-for-http-certificate-in-elastic-cluster/267009/11 "2021-04-16T00:32:17Z")

</div>

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