Generate a node private key and certificate

This step creates a private key and certificate that the node will use to identify itself. This step must be done for every node.

keytool -genkey can generate a private key and certificate for your node. The following is a typical usage:

keytool -genkey                  \
        -alias     node01        \ 
        -keystore  node01.jks    \ 
        -keyalg    RSA           \
        -keysize   2048          \
        -validity  712           \
        -ext san=dns:node01.example.com,ip:192.168.1.1

	An alias for this public/private key-pair.
	The keystore for this node — will be created.
	The `SubjectAlternativeName` list for this host. The -ext parameter is optional and can be used to specify additional DNS names and IP Addresses that the certificate will be valid for. Multiple DNS and IP entries can be specified by separating each entry with a comma. If this option is used, all names and ip addresses must be specified in this list.

This will create an RSA public/private key-pair with a key size of 2048 bits and store them in the node01.jks file. The keystore is protected with the password of myPass. The 712 argument specifies the number of days that the certificate is valid for — two years, in this example.

The tool will prompt you for information to include in the certificate.

Specifying the Node Identity

An Elasticsearch node with Shield will verify the hostname contained in the certificate of each node it connects to. Therefore it is important that each node’s certificate contains the hostname or IP address used to connect to the node. Hostname verification can be disabled, for more information see the Configuration Parameters for TLS/SSL section.

The recommended way to specify the node identity is by providing all names and IP addresses of a node as a SubjectAlternativeName list using the the -ext option. When using a commercial CA, internal DNS names and private IP addresses will not be accepted as a SubjectAlternativeName due to security concerns; only publicly resolvable DNS names and IP addresses will be accepted. The use of an internal CA is the most secure option for using private DNS names and IP addresses, as it allows for node identity to be specified and verified. If you must use a commercial CA and private DNS names or IP addresses, you will not be able to include the node identity in the certificate and will need to disable hostname verification.

Another way to specify node identity is by using the CommonName attribute of the certificate. The first prompt from keytool, What is your first and last name?, is asking for the CommonName attribute of certificate. When using the CommonName attribute for node identity, a DNS name must be used. The rest of the prompts by keytool are for information only.

At the end, you will be prompted to optionally enter a password. The command line argument specifies the password for the keystore. This prompt is asking if you want to set a different password that is specific to this certificate. Doing so may provide some incremental improvement to security.

Here is a sample interaction with keytool -genkey

What is your first and last name?
  [Unknown]:  node01.example.com 
What is the name of your organizational unit?
  [Unknown]:  test
What is the name of your organization?
  [Unknown]:  Elasticsearch
What is the name of your City or Locality?
  [Unknown]:  Amsterdam
What is the name of your State or Province?
  [Unknown]:  Amsterdam
What is the two-letter country code for this unit?
  [Unknown]:  NL
Is CN=node01.example.com, OU=test, O=elasticsearch, L=Amsterdam, ST=Amsterdam, C=NL correct?
  [no]:  yes

Enter key password for <mydomain>
    (RETURN if same as keystore password):

The DNS name or hostname of the node must be used here if you do not specify a SubjectAlternativeName list using the -ext option.

Now you have a certificate and private key stored in node01.jks.

« Set up a keystore Create a certificate signing request »