Creating local SSL certificate and keystore files (2024)

For each node in the cluster, create a keystore, key pair, and certificate signing request using the FQDN of the 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.

Note: 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.10Address: 10.200.1.10#53Name: ip-10-200-182-183.example.comAddress: 10.200.182.183ip-10-200-182-183.example.com10.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 will have its own keystore, such as node1-keystore.jks:

Important: 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"
```
Note: The -validity option specifies how long the generated key pair for the node is valid for. 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. If 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.

truststore_password

Password required to access the keystore.

keystore_password

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

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
If 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: JKSKeystore provider: SUNYour keystore contains 1 entrydc1_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.

keystore_password

Password used to protect the private key of the key pair.
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).