Untitled | DataStax Enterprise

Creating a key and certificate for each node

For each node in the cluster, create a keystore, key pair, and certificate signing request using the Fully Qualified Domain Name (FQDN) of the node.

These steps are required even when using a third-party CA, or when adding a node to an existing DSE environment with SSL enabled.

Prerequisites

On each node, run the following command to obtain the FQDN for each node:

nslookup $(hostname --fqdn) && hostname --fqdn && hostname -i

Server:    10.200.1.10
Address:   10.200.1.10#53

Name:      ip-10-200-182-183.example.com
Address:   10.200.182.183

ip-10-200-182-183.example.com
10.200.182.183

In this example, ip-10-200-182-183.example.com is the Common Name (CN), which is used to generate the SSL certificate. The CN must match the DNS-resolvable host name. Mismatches between the CN and node hostname cause an exception and the connection is refused.

Procedure

Create a directory to store the keystores and change to the directory:
```
mkdir -p <dse/keystores>
```
```
cd <dse/keystores>
```

For each node, generate a keystore with key pair. Each node is to have its own keystore, such as node1-keystore.jks:

Ensure the passwords entered for <truststore_password> and <keystore_password> are the same. If the passwords are different, DSE fails to start and returns an error message: “Cannot recover key”.

keytool -genkeypair -keyalg RSA \
-alias <node_name> \
-keystore <node-keystore.jks> \
-storepass <truststore_password> \
-keypass <keystore_password> \
-validity 730 \
-keysize 2048 \
-dname "CN=<node_name>, OU=<cluster_name>, O=<org_name>, C=<CC>" \
-ext "san=ip:<node_ip_address>"

The -validity option specifies the timeframe for which the generated key pair for the node is valid. In the previous example the key pair is valid for 730 days, which is approximately 2 years.

node_name

Fully Qualified Domain Name (FQDN) of the node, such as ip-10-200-182-183.example.com. When using the FQDN as the node_name, you can add the IP address as a subject alternative name (SAN) so that the certificate protects the IP address in addition to the domain name.

node-keystore.jks

Keystore for the individual node.

Default: none

truststore_password

Password required to access the keystore.

Default: none

keystore_password

Password used to protect the private key of the key pair.

Default: none

cluster_name

Name of your DataStax Enterprise (DSE) cluster.

org_name

Name of your organization.

CC

Two letter country code, such as US for United States or JP for Japan. See Nations Online for a complete list of country codes.

node_ip_address

When using the domain name as the node_name for the CA, add san=ip:ip_address to the -ext option. Using the IP address as a subject alternative name (SAN) ensures that the certificate protects the IP address in addition to the domain name.

For example:

-ext "san=ip:10.200.100.52"

Verify each SSL keystore and key pair:

keytool -list \
-keystore <node-keystore.jks> \
-storepass <truststore_password>

The command output indicates the keystore type, provider, and number of entries. The alias used the example is dc1_node1.

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

dc1_node1, Jul 23, 2019, PrivateKeyEntry,
Certificate fingerprint (SHA1): <SHA1_hash>

Generate a signing request from each keystore:
```
keytool -keystore <node-keystore.jks> \
-alias <node_name> \
-certreq -file <signing_request.csr> \
-keypass <node-key_password> \
-storepass <keystore_password>
```
node-key_password

Password used to protect the individual private key.

Default: none

keystore_password

Password used to protect the private key of the key pair.

Default: none

The certificate signing request file (<signing_request.csr>) is created.
Repeat the previous steps on each node to generate a signing request, ensuring that the dname information matches the node information (such as <node_name> and <cluster_name>).

Creating a key and certificate for each node

Prerequisites

Procedure

Was this helpful?

Give Feedback