Encryption and Certificates

Shield allows for the installation of X.509 certificates that establish trust between nodes. When a client connects to a node using SSL or TLS, the node will present its certificate to the client, and then as part of the handshake process the node will prove that it owns the private key linked with the certificate. The client will then determine if the node’s certificate is valid, trusted, and matches the hostname or IP address it is trying to connect to. A node also acts as a client when connecting to other nodes in the cluster, which means that every node must trust all of the other nodes in the cluster.

The certificates used for SSL and TLS can be signed by a certificate authority (CA) or self-signed. The type of signing affects how a client will trust these certificates. Self-signed certificates must be trusted individually, which means that each node must have every other node’s certificate installed. Certificates signed by a CA, can be trusted through validation that the CA signed the certificate. This means that every node will only need the signing CA certificate installed to trust the other nodes in the cluster.

The best practice with Shield is to use certificates signed by a CA. Self-signed certificates introduce a lot of overhead as they require each client to trust every self-signed certificate. Self-signed certificates also limit the elasticity of elasticsearch as adding a new node to the cluster requires a restart of every node after installing the new node’s certificate. This overhead is not present when using a CA as a new node only needs a certificate signed by the CA to establish trust with the other nodes in the cluster.

Many organizations have a CA to sign certificates for each nodes. If not, see Appendix - Certificate Authority for instructions on setting up a CA.

The following steps will need to be repeated on each node to setup SSL/TLS:

The steps in this procedure use the keytool command-line utility.