94 lines
4.3 KiB
Plaintext
94 lines
4.3 KiB
Plaintext
|
[[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.
|