# Manually-configured security in cluster

**URL:** <https://discuss.elastic.co/t/manually-configured-security-in-cluster/325708>\
**Category:** Elasticsearch\
**Tags:** elastic-stack-security\
**Created:** [February 16, 2023, 9:46am UTC](https://discuss.elastic.co/t/manually-configured-security-in-cluster/325708 "2023-02-16T09:46:13Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![frank\_2](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/frank_2/32/108198_2.png) [@frank\_2](https://discuss.elastic.co/u/frank_2)\
**Post date:** [February 16, 2023, 9:46am UTC](https://discuss.elastic.co/t/manually-configured-security-in-cluster/325708/1 "2023-02-16T09:46:14Z")

</div>

Hello,

I'm following the [guide on how to manually set up security within a cluster](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-basic-setup.html). Am I right in thinking that the instructions tell the reader to copy the same transport certificate and key to every node in the cluster?

Is this the recommended security practice - to share one cert/key between multiple nodes? Surely each node should have its own certificates issued so that they can be revoked individually should a node be compromised?

Is there a similar guide for PEM-based certificates, please?

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [February 19, 2023, 9:52pm UTC](https://discuss.elastic.co/t/manually-configured-security-in-cluster/325708/2 "2023-02-19T21:52:44Z")

</div>

Yes the simple example is to copy to all you will also see a note that says

> If you want to use hostname verification, set the verification mode to full. You should generate a different certificate for each host that matches the DNS or IP address. See the xpack.security.transport.ssl.verification\_mode parameter in TLS settings.

But if you want you can just generate for each anyways.

If you look at the actual utility [here](https://www.elastic.co/guide/en/elasticsearch/reference/current/certutil.html):

You can use an instances file and define / create them all at once time

And there is a `--pem` flag as well to get `.pem` format

---

<div class="post-metadata">

**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\
**Post date:** [February 20, 2023, 12:22am UTC](https://discuss.elastic.co/t/manually-configured-security-in-cluster/325708/3 "2023-02-20T00:22:56Z")

</div>

> [@frank\_2](#):
>
> Is there a similar guide for PEM-based certificates, please?

You basically just need to use the `--pem` parameter, this will create `crt` and `key` file.

I made a short tutorial on how to manually configure security on a cluster a couple of time ago, maybe this [help](https://web.leandrojmp.com/posts/en/2022/10/elasticsearch-security).

---

<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:** [February 22, 2023, 1:23am UTC](https://discuss.elastic.co/t/manually-configured-security-in-cluster/325708/4 "2023-02-22T01:23:42Z")

</div>

> [@frank\_2](#):
>
> Surely each node should have its own certificates issued so that they can be revoked individually should a node be compromised?

Elasticsearch doesn't support revocation lists, so if you have a compromised node then you will need to re-key the whole cluster, even if you had separate certificates per node.

---

<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:** [March 22, 2023, 1:24am UTC](https://discuss.elastic.co/t/manually-configured-security-in-cluster/325708/5 "2023-03-22T01:24:41Z")

</div>

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