mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-03-27 18:38:41 +00:00
[DOCS] Move appropriate TLS content to Elasticsearch Ref (elastic/x-pack-elasticsearch#3416)
Original commit: elastic/x-pack-elasticsearch@a5f96bd7a2
This commit is contained in:
Lisa Cawley
GitHub
parent
860014ff5b
commit
1369a49b9f
docs/en
@ -11,4 +11,8 @@ such as encrypting communications, role-based access control, IP filtering, and
|
||||
auditing. For more information, see
|
||||
{xpack-ref}/xpack-security.html[Securing the Elastic Stack].
|
||||
|
||||
include::securing-communications/securing-elasticsearch.asciidoc[]
|
||||
include::securing-communications/configuring-tls-docker.asciidoc[]
|
||||
include::securing-communications/enabling-cipher-suites.asciidoc[]
|
||||
include::securing-communications/separating-node-client-traffic.asciidoc[]
|
||||
include::{xes-repo-dir}/settings/security-settings.asciidoc[]
|
||||
|
||||
@ -18,6 +18,14 @@ cluster and receiving data through replication.
|
||||
|
||||
include::securing-communications/setting-up-ssl.asciidoc[]
|
||||
|
||||
include::securing-communications/enabling-cipher-suites.asciidoc[]
|
||||
//TO-DO: These sections can be removed when all links to them are removed.
|
||||
|
||||
include::securing-communications/separating-node-client-traffic.asciidoc[]
|
||||
[[ciphers]]
|
||||
=== Enabling Cipher Suites for Stronger Encryption
|
||||
|
||||
See {ref}/ciphers.html[Enabling Cipher Suites for Stronger Encryption].
|
||||
|
||||
[[separating-node-client-traffic]]
|
||||
=== Separating node-to-node and client traffic
|
||||
|
||||
See {ref}/separating-node-client-traffic.html[Separating node-to-node and client traffic].
|
||||
|
||||
@ -1,3 +1,4 @@
|
||||
[role="xpack"]
|
||||
[[ciphers]]
|
||||
=== Enabling Cipher Suites for Stronger Encryption
|
||||
|
||||
|
||||
@ -0,0 +1,93 @@
|
||||
[[node-certificates]]
|
||||
==== Generating Node Certificates
|
||||
|
||||
TLS requires X.509 certificates to perform encryption and authentication of the
|
||||
application that is being communicated with. In order for the communication
|
||||
between nodes to be truly secure, the certificates must be validated. The
|
||||
recommended approach for validating certificate authenticity in a {es} cluster
|
||||
is to trust the certificate authority (CA) that signed the certificate. By doing
|
||||
this, as nodes are added to your cluster they just need to use a certificate
|
||||
signed by the same CA and the node is automatically allowed to join the cluster.
|
||||
Additionally, it is recommended that the certificates contain subject alternative
|
||||
names (SAN) that correspond to the node's IP address and DNS name so that
|
||||
hostname verification can be performed.
|
||||
|
||||
In order to simplify the process of generating certificates for the Elastic
|
||||
Stack, a command line tool, {ref}/certutil.html[`certutil`] has been included
|
||||
with {xpack}. This tool takes care of generating a CA and signing certificates
|
||||
with the CA. `certutil` can be used interactively or in a silent mode through
|
||||
the use of an input file. The `certutil` tool also supports generation of
|
||||
certificate signing requests (CSR), so that a commercial- or
|
||||
organization-specific CA can be used to sign the certificates. For example:
|
||||
|
||||
. Optional: Create a certificate authority for your {es} cluster.
|
||||
+
|
||||
--
|
||||
For example, use the `certutil ca` command:
|
||||
|
||||
[source,shell]
|
||||
----------------------------------------------------------
|
||||
bin/x-pack/certutil ca
|
||||
----------------------------------------------------------
|
||||
|
||||
You can configure the cluster to trust all nodes that have a certificate that
|
||||
has been signed by this CA.
|
||||
|
||||
The command outputs a single file, with a default name of `elastic-stack-ca.p12`.
|
||||
This file is a PKCS#12 keystore that contains the public certificate for your CA
|
||||
and the private key that is used to sign the certificates for each node.
|
||||
|
||||
The `certutil` command also prompts you for a password to protect the file and
|
||||
key. If you plan to add more nodes to your cluster in the future, retain a copy
|
||||
of the file and remember its password.
|
||||
--
|
||||
|
||||
. Generate a certificate and private key for for each node in your cluster.
|
||||
+
|
||||
--
|
||||
For example, use the `certutil cert` command:
|
||||
|
||||
[source,shell]
|
||||
----------------------------------------------------------
|
||||
bin/x-pack/certutil cert --ca elastic-stack-ca.p12
|
||||
----------------------------------------------------------
|
||||
The output is a single PKCS#12 keystore that includes the node certificate, node
|
||||
key, and CA certificate.
|
||||
|
||||
You are also prompted for a password. You can enter a password for your
|
||||
certificate and key, or you can leave the password blank by pressing Enter.
|
||||
|
||||
By default `certutil` generates certificates that have no hostname information
|
||||
in them (that is, they do not have any Subject Alternative Name fields).
|
||||
This means that you can use the certificate for every node in your cluster, but
|
||||
you must turn off hostname verification as shown in the configuration below.
|
||||
|
||||
If you want to use hostname verification within your cluster, run the
|
||||
`certutil cert` command once for each of your nodes and provide the `--name`,
|
||||
`--dns` and `--ip` options.
|
||||
|
||||
NOTE: You should secure the output files, since they contain the private keys
|
||||
for your instance.
|
||||
|
||||
Alternatively, if you want to use a commercial or organization-specific CA,
|
||||
you can use the `certutil csr` command to generate certificate signing requests
|
||||
(CSR) for the nodes in your cluster. For more information, see <<certutil>>.
|
||||
--
|
||||
|
||||
. Copy the node certificate to the appropriate locations.
|
||||
+
|
||||
--
|
||||
Copy the applicable `.p12` file into a directory within the {es} configuration
|
||||
directory on each node. For example, `/home/es/config/certs`. There is no need
|
||||
to copy the CA file to this directory.
|
||||
|
||||
For each additional Elastic product that you want to configure, copy the
|
||||
certificates to the relevant configuration directory. For more information, see
|
||||
<<enable-ssl>>.
|
||||
--
|
||||
|
||||
NOTE: If you choose not to use `certutil`, the certificates that you obtain must
|
||||
allow for both `clientAuth` and `serverAuth` if the extended key usage extension
|
||||
is present. The certificates need to be in PEM or PKCS#12 format. Although not
|
||||
required, it is highly recommended that the certificate contain the DNS names
|
||||
and/or IP addresses of the node so that hostname verification can be used.
|
||||
102
docs/en/security/securing-communications/node-config.asciidoc
Normal file
102
docs/en/security/securing-communications/node-config.asciidoc
Normal file
@ -0,0 +1,102 @@
|
||||
[[enable-ssl]]
|
||||
==== Enabling TLS on {es} Nodes
|
||||
|
||||
Once you have the signed certificate, private key, and CA certificate you need
|
||||
to modify the node configuration to enable Transport Layer Security (TLS/SSL).
|
||||
|
||||
. Specify the information required to access the node's certificate.
|
||||
|
||||
** If the certificate is in PKCS#12 format, add the following information to the
|
||||
`elasticsearch.yml` file on each node:
|
||||
+
|
||||
--
|
||||
[source,yaml]
|
||||
-----------------------------------------------------------
|
||||
xpack.ssl.keystore.path: certs/elastic-certificates.p12 <1>
|
||||
xpack.ssl.truststore.path: certs/elastic-certificates.p12 <2>
|
||||
-----------------------------------------------------------
|
||||
<1> If you created a separate certificate for each node, then you might need to
|
||||
customize this path on each node. If the filename matches the node name, you can
|
||||
use the `certs/${node.name}.p12` format, for example.
|
||||
<2> The `certutil` output includes the CA certificate inside the PKCS#12
|
||||
keystore, therefore the keystore can also be used as the truststore. This name
|
||||
should match the `keystore.path` value.
|
||||
--
|
||||
|
||||
** If the certificate is in PEM format, add the following information to the
|
||||
`elasticsearch.yml` file on each node:
|
||||
+
|
||||
--
|
||||
[source, yaml]
|
||||
--------------------------------------------------
|
||||
xpack.ssl.key: /home/es/config/x-pack/node01.key <1>
|
||||
xpack.ssl.certificate: /home/es/config/x-pack/node01.crt <2>
|
||||
xpack.ssl.certificate_authorities: [ "/home/es/config/x-pack/ca.crt" ] <3>
|
||||
--------------------------------------------------
|
||||
<1> The full path to the node key file. This must be a location within the
|
||||
{es} configuration directory.
|
||||
<2> The full path to the node certificate. This must be a location within the
|
||||
{es} configuration directory.
|
||||
<3> An array of paths to the CA certificates that should be trusted. These paths
|
||||
must be a location within the {es} configuration directory.
|
||||
--
|
||||
|
||||
. If you secured the node's certificate with a password, add the password to
|
||||
your {es} keystore:
|
||||
+
|
||||
--
|
||||
[source,shell]
|
||||
-----------------------------------------------------------
|
||||
bin/elasticsearch-keystore add xpack.ssl.keystore.secure_password
|
||||
|
||||
bin/elasticsearch-keystore add xpack.ssl.truststore.secure_password
|
||||
-----------------------------------------------------------
|
||||
--
|
||||
|
||||
. Enable TLS on the transport networking layer to ensure that communication
|
||||
between nodes is encrypted. Make the following changes in `elasticsearch.yml`:
|
||||
+
|
||||
--
|
||||
[source, yaml]
|
||||
--------------------------------------------------
|
||||
xpack.security.transport.ssl.enabled: true
|
||||
xpack.security.transport.ssl.verification_mode: certificate <1>
|
||||
--------------------------------------------------
|
||||
<1> If you used the `--dns` or `--ip` options with the `certutil cert` command
|
||||
and you want to enable strict hostname checking, set the verification mode to
|
||||
`full`.
|
||||
--
|
||||
|
||||
. Optional: Enable TLS on the HTTP layer to ensure that communication between HTTP clients
|
||||
and the cluster is encrypted.
|
||||
+
|
||||
--
|
||||
NOTE: Enabling TLS on the HTTP layer is strongly recommended but is not required.
|
||||
If you enable TLS on the HTTP layer in {es}, then you might need to make
|
||||
configuration changes in other parts of the Elastic Stack and in any {es}
|
||||
clients that you use.
|
||||
|
||||
Make the following changes in `elasticsearch.yml`:
|
||||
|
||||
[source, yaml]
|
||||
--------------------------------------------------
|
||||
xpack.security.http.ssl.enabled: true
|
||||
--------------------------------------------------
|
||||
--
|
||||
|
||||
. Restart {es}.
|
||||
+
|
||||
--
|
||||
You must perform a full cluster restart. Nodes which are configured to use TLS
|
||||
cannot communicate with nodes that are using unencrypted networking (and
|
||||
vice-versa). After enabling TLS you must restart all nodes in order to maintain
|
||||
communication across the cluster.
|
||||
--
|
||||
|
||||
NOTE: All TLS-related node settings are considered to be highly sensitive and
|
||||
therefore are not exposed via the
|
||||
{ref}/cluster-nodes-info.html#cluster-nodes-info[nodes info API] For more
|
||||
information about any of these settings, see <<security-settings>>.
|
||||
|
||||
For information about configuring other products in the Elastic Stack, see
|
||||
{xpack-ref}/ssl-tls.html[Setting Up TLS on a Cluster].
|
||||
@ -0,0 +1,28 @@
|
||||
[role="xpack"]
|
||||
[[configuring-tls]]
|
||||
=== Encrypting Communications in {es}
|
||||
|
||||
{security} enables you to encrypt traffic to, from, and within your {es} cluster.
|
||||
Connections are secured using Transport Layer Security (TLS/SSL).
|
||||
|
||||
WARNING: Clusters that do not have encryption enabled send all data in plain text
|
||||
including passwords and will not be able to install a license that enables {security}.
|
||||
|
||||
To enable encryption, you need to perform the following steps on each node in
|
||||
the cluster:
|
||||
|
||||
. <<installing-xpack-es,Install {xpack} into {es}>>.
|
||||
|
||||
. <<node-certificates, Generate a private key and X.509 certificate>>.
|
||||
|
||||
. <<enable-ssl, Configure each node>> to:
|
||||
.. Identify itself using its signed certificate.
|
||||
.. Required: Enable SSL on the transport layer.
|
||||
.. Recommended: Enable SSL on the HTTP layer.
|
||||
. Restart {es}.
|
||||
|
||||
For more information about encrypting communications across the Elastic Stack,
|
||||
see {xpack-ref}/encrypting-communications.html[Encrypting Communications].
|
||||
|
||||
include::node-certificates.asciidoc[]
|
||||
include::node-config.asciidoc[]
|
||||
@ -1,3 +1,4 @@
|
||||
[role="xpack"]
|
||||
[[separating-node-client-traffic]]
|
||||
=== Separating node-to-node and client traffic
|
||||
|
||||
@ -35,7 +36,8 @@ transport.profiles.client.bind_host: 1.1.1.1 <2>
|
||||
<1> The bind address for the network that will be used for node-to-node communication
|
||||
<2> The bind address for the network used for client communication
|
||||
|
||||
If separate networks are not available, then <<ip-filtering, IP Filtering>> can
|
||||
If separate networks are not available, then
|
||||
{xpack-ref}/ip-filtering.html[IP Filtering] can
|
||||
be enabled to limit access to the profiles.
|
||||
|
||||
When using SSL for transport, a different set of certificates can also be used
|
||||
@ -62,4 +64,5 @@ transport.profiles.client.xpack.security.ssl.client_authentication: none
|
||||
|
||||
This setting keeps certificate authentication active for node-to-node traffic,
|
||||
but removes the requirement to distribute a signed certificate to transport
|
||||
clients. Please see the <<transport-client, Transport Client>> section.
|
||||
clients. For more information, see
|
||||
{xpack-ref}/java-clients.html#transport-client[Configuring the Transport Client to work with a Secured Cluster].
|
||||
|
||||
@ -1,117 +1,50 @@
|
||||
[[ssl-tls]]
|
||||
=== Setting Up SSL/TLS on a Cluster
|
||||
=== Setting Up TLS on a Cluster
|
||||
|
||||
{security} enables you to encrypt traffic to, from, and within your Elasticsearch
|
||||
{security} enables you to encrypt traffic to, from, and within your {es}
|
||||
cluster. Connections are secured using Transport Layer Security (TLS), which is
|
||||
commonly referred to as "SSL".
|
||||
|
||||
WARNING: Clusters that do not have encryption enabled send all data in plain text
|
||||
including passwords and will not be able to install a license that enables {security}.
|
||||
|
||||
To enable encryption, you need to perform the following steps on each node in
|
||||
the cluster:
|
||||
The following steps describe how to enable encryption across the various
|
||||
components of the Elastic Stack. You must perform each of the steps that are
|
||||
applicable to your cluster.
|
||||
|
||||
. <<installing-node-certificates, Generate a private key and X.509 certificate>>.
|
||||
. Generate a private key and X.509 certificate for each of your {es} nodes. See
|
||||
{ref}/node-certificates.html[Generating Node Certificates].
|
||||
|
||||
. <<configure-ssl, Configure the node>> to:
|
||||
.. Identify itself using its signed certificate.
|
||||
.. Enable SSL on the transport and HTTP layers.
|
||||
. Configure each node in the cluster to identify itself using its signed
|
||||
certificate and enable TLS on the transport layer. You can also optionally
|
||||
enable TLS on the HTTP layer. See
|
||||
{ref}/enable-ssl.html[Enabling TLS on {es} Nodes].
|
||||
|
||||
. Restart Elasticsearch.
|
||||
. Configure {monitoring} to use encrypted connections. See <<secure-monitoring>>.
|
||||
|
||||
. Configure {kib} to encrypt communications between the browser and
|
||||
the {kib} server and to connect to {es} via HTTPS. See
|
||||
{kibana-ref}/using-kibana-with-security.html[Configuring Security in {kib}].
|
||||
|
||||
. Configure Logstash to use TLS encryption. See
|
||||
{logstash-ref}/ls-security.html[Configuring Security in Logstash].
|
||||
|
||||
. Configure Beats to use encrypted connections. See <<beats>>.
|
||||
|
||||
. Configure the Java transport client to use encrypted communications.
|
||||
See <<java-clients>>.
|
||||
|
||||
. Configure {es} for Apache Hadoop to use secured transport. See
|
||||
{hadoop-ref}/security.html[{es} for Apache Hadoop Security].
|
||||
|
||||
//The following sections can be removed after we clean up all links to these anchors.
|
||||
|
||||
[[installing-node-certificates]]
|
||||
==== Generating Node Certificates
|
||||
|
||||
TLS requires X.509 certificates to perform encryption and authentication of the application
|
||||
that is being communicated with. In order for the communication between nodes to be truly
|
||||
secure, the certificates must be validated. The recommended approach for validating
|
||||
certificate authenticity in a Elasticsearch cluster is to trust the certificate authority (CA)
|
||||
that signed the certificate. By doing this, as nodes are added to your cluster they just need
|
||||
to use a certificate signed by the same CA and the node is automatically allowed to join the
|
||||
cluster. Additionally, it is recommended that the certificates contain subject alternative
|
||||
names (SAN) that correspond to the node's IP address and DNS name so that hostname verification
|
||||
can be performed.
|
||||
|
||||
In order to simplify the process of generating certificates for the Elastic Stack, a command
|
||||
line tool, {ref}/certutil.html[`certutil`] has been included with {xpack}. This
|
||||
tool takes care of the generating
|
||||
a CA and signing certificates with the CA. `certutil` can be used interactively or in a silent
|
||||
mode through the use of an input file. The `certutil` tool also supports generation of certificate
|
||||
signing requests (CSR), so that a commercial or organization specific CA can be used to sign
|
||||
the certificates. For example:
|
||||
|
||||
1. Optional: Create a certificate authority by using the `certutil ca` command.
|
||||
2. Generate a certificate for each node by using the `certutil cert` command.
|
||||
+
|
||||
--
|
||||
NOTE: You should secure the output files, since they contain the private keys
|
||||
for your instance.
|
||||
|
||||
--
|
||||
3. Copy the node certificate to the appropriate locations. For each Elastic
|
||||
product that you want to configure, copy the certificates to the relevant
|
||||
configuration directory. For more information, see
|
||||
<<enable-ssl,Configuring security in {es}>>,
|
||||
{kibana-ref}/using-kibana-with-security.html[Configuring security in {kib}], and
|
||||
{logstash-ref}/ls-security.html[Configuring security in Logstash].
|
||||
|
||||
NOTE: If you choose not to use `certutil`, the certificates that you obtain must allow for both
|
||||
`clientAuth` and `serverAuth` if the extended key usage extension is present. The certificates
|
||||
need to be in PEM or PKCS#12 format. Although not required, it is highly recommended that the certificate contain
|
||||
the DNS names and/or IP addresses of the node so that hostname verification can be used.
|
||||
==== Node Certificates
|
||||
|
||||
See {ref}/node-certificates.html[Generating Node Certificates].
|
||||
|
||||
[[enable-ssl]]
|
||||
==== Enabling SSL in the Node Configuration
|
||||
==== Enabling TLS in the Node Configuration
|
||||
|
||||
Once you have the signed certificate, private key, and CA certificate you need to
|
||||
modify the node configuration to enable SSL.
|
||||
|
||||
[[configure-ssl]]
|
||||
To enable SSL, make the following changes in `elasticsearch.yml`:
|
||||
|
||||
. Specify the location of the node's keystore and the password(s) needed to
|
||||
access the node's certificate. For example:
|
||||
+
|
||||
--
|
||||
[source, yaml]
|
||||
--------------------------------------------------
|
||||
xpack.ssl.key: /home/es/config/x-pack/node01.key <1>
|
||||
xpack.ssl.certificate: /home/es/config/x-pack/node01.crt <2>
|
||||
xpack.ssl.certificate_authorities: [ "/home/es/config/x-pack/ca.crt" ] <3>
|
||||
--------------------------------------------------
|
||||
<1> The full path to the node key file. This must be a location within the
|
||||
Elasticsearch configuration directory.
|
||||
<2> The full path to the node certificate. This must be a location within the
|
||||
Elasticsearch configuration directory.
|
||||
<3> An array of paths to the CA certificates that should be trusted. These paths
|
||||
must be a location within the Elasticsearch configuration directory.
|
||||
--
|
||||
|
||||
. Enable SSL on the transport networking layer to ensure that communication
|
||||
between nodes is encrypted:
|
||||
+
|
||||
[source, yaml]
|
||||
--------------------------------------------------
|
||||
xpack.security.transport.ssl.enabled: true
|
||||
--------------------------------------------------
|
||||
+
|
||||
. Enable SSL on the HTTP layer to ensure that communication between HTTP clients
|
||||
and the cluster is encrypted:
|
||||
+
|
||||
[source, yaml]
|
||||
--------------------------------------------------
|
||||
xpack.security.http.ssl.enabled: true
|
||||
--------------------------------------------------
|
||||
+
|
||||
|
||||
. Restart Elasticsearch.
|
||||
+
|
||||
You must perform a full cluster restart. Nodes which are configured to use
|
||||
SSL/TLS cannot communicate with nodes that are using unencrypted networking
|
||||
(and vice-versa). After enabling SSL/TLS you must restart all nodes in order
|
||||
to maintain communication across the cluster.
|
||||
|
||||
NOTE: All SSL related node settings that are considered to be highly sensitive
|
||||
and therefore are not exposed via the
|
||||
{ref}/cluster-nodes-info.html#cluster-nodes-info[nodes info API].
|
||||
See {ref}/enable-ssl.html[Enabling TLS on {es} Nodes].
|
||||
|
||||
@ -9,5 +9,5 @@ include::{asciidoc-dir}/../../shared/settings.asciidoc[]
|
||||
include::license-settings.asciidoc[]
|
||||
include::ml-settings.asciidoc[]
|
||||
include::monitoring-settings.asciidoc[]
|
||||
include::security-settings.asciidoc[]
|
||||
//include::security-settings.asciidoc[]
|
||||
include::notification-settings.asciidoc[]
|
||||
|
||||
@ -159,95 +159,9 @@ information, see
|
||||
{xpack-ref}/encrypting-communications.html[Encrypting Communications].
|
||||
|
||||
--
|
||||
.. Generate node certificates. For example, you can use the `certutil` command
|
||||
line tool to generate a certificate authority (CA) and signed certificates for
|
||||
your nodes. For more information, see <<certutil>>.
|
||||
.. <<node-certificates,Generate node certificates for each of your {es} nodes>>.
|
||||
|
||||
... Generate a new Certificate Authority (CA) for your {es} cluster:
|
||||
+
|
||||
--
|
||||
[source,shell]
|
||||
----------------------------------------------------------
|
||||
bin/x-pack/certutil ca
|
||||
----------------------------------------------------------
|
||||
|
||||
You can configure the cluster to trust all nodes that have a certificate that
|
||||
has been signed by this CA.
|
||||
|
||||
The command outputs a single file, with a default name of `elastic-stack-ca.p12`.
|
||||
This file is a PKCS#12 keystore that contains the public certificate for your CA
|
||||
and the private key that is used to sign the certificates for each node.
|
||||
|
||||
The `certutil` command also prompts you for a password to protect the file and
|
||||
key. If you plan to add more nodes to your cluster in the future, retain a copy
|
||||
of the file and remember its password.
|
||||
--
|
||||
|
||||
... Generate a certificate and private key for each node in your cluster:
|
||||
+
|
||||
--
|
||||
[source,shell]
|
||||
----------------------------------------------------------
|
||||
bin/x-pack/certutil cert --ca elastic-stack-ca.p12
|
||||
----------------------------------------------------------
|
||||
The output is a single PKCS#12 keystore that includes the node certificate, node
|
||||
key, and CA certificate.
|
||||
|
||||
You are also prompted for a password. You can enter a password for your
|
||||
certificate and key, or you can leave the password blank by pressing Enter.
|
||||
|
||||
By default `certutil` generates certificates that have no hostname information
|
||||
in them (that is, they do not have any Subject Alternative Name fields).
|
||||
This means that you can use the certificate for every node in your cluster, but
|
||||
you must turn off hostname verification as shown in the configuration below.
|
||||
|
||||
If you want to use hostname verification within your cluster, run the
|
||||
`certutil cert` command once for each of your nodes and provide the `--name`,
|
||||
`--dns` and `--ip` options.
|
||||
--
|
||||
... Alternatively, if you want to use a commercial or organization-specific CA,
|
||||
you can use the `certutil csr` command to generate certificate signing requests
|
||||
(CSR) for the nodes in your cluster. For more information, see <<certutil>>.
|
||||
|
||||
.. Copy the applicable `.p12` file into a directory within the {es} configuration
|
||||
directory on each node. For example, `/home/es/config/certs`. There is no need
|
||||
to copy the CA file to this directory.
|
||||
|
||||
.. Add the following information to the `elasticsearch.yml` file on each node:
|
||||
+
|
||||
--
|
||||
[source,yaml]
|
||||
-----------------------------------------------------------
|
||||
xpack.ssl.keystore.path: certs/elastic-certificates.p12 <1>
|
||||
xpack.ssl.truststore.path: certs/elastic-certificates.p12 <2>
|
||||
xpack.security.transport.ssl.verification_mode: certificate <3>
|
||||
xpack.security.transport.ssl.enabled: true
|
||||
-----------------------------------------------------------
|
||||
<1> If you created a separate certificate for each node, then you might need to
|
||||
customize this path on each node. If the filename matches the node name, you can
|
||||
use the `certs/${node.name}.p12` format, for example.
|
||||
<2> The `certutil` output includes the CA certificate inside the PKCS#12
|
||||
keystore, therefore the keystore can also be used as the truststore. This name
|
||||
should match the `keystore.path` value.
|
||||
<3> If you used the `--dns` or `--ip` options with the `certutil cert` command
|
||||
and you want to enable strict hostname checking, set the verification mode to
|
||||
`full`.
|
||||
|
||||
For more information about these settings, see
|
||||
{ref}/security-settings.html[Security Settings in {es}].
|
||||
--
|
||||
|
||||
.. If you secured the node's PKCS#12 file with a password, then you must add
|
||||
the password to your {es} keystore. Run the following commands:
|
||||
+
|
||||
--
|
||||
[source,shell]
|
||||
-----------------------------------------------------------
|
||||
bin/elasticsearch-keystore add xpack.ssl.keystore.secure_password
|
||||
|
||||
bin/elasticsearch-keystore add xpack.ssl.truststore.secure_password
|
||||
-----------------------------------------------------------
|
||||
--
|
||||
.. <<enable-ssl, Enable TLS on each {es} node>>.
|
||||
|
||||
. Start {es}.
|
||||
+
|
||||
|
||||
@ -11,7 +11,7 @@ easy-to-install package. To access this functionality, you must
|
||||
--
|
||||
|
||||
include::installing-xes.asciidoc[]
|
||||
include::{xes-repo-dir}/settings/configuring-xes.asciidoc[]
|
||||
include::setup-xclient.asciidoc[]
|
||||
include::bootstrap-checks-xes.asciidoc[]
|
||||
include::{xes-repo-dir}/security/configuring-es.asciidoc[]
|
||||
include::setup-xclient.asciidoc[]
|
||||
include::{xes-repo-dir}/settings/configuring-xes.asciidoc[]
|
||||
include::bootstrap-checks-xes.asciidoc[]
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user