Setting up SSL certificates

General steps for generating certificate signing requests, signing, and creating a keystore and truststore for development and production environments.

Use SSL certificates for client-to-node encryption and node-to-node encryption. DataStax supports SSL using well-known CA signed certificates for each node or with bring your own (BYO) root Certificate Authority.

Note: DataStax recommends using certificates signed by a CA to reduce SSL certificate management tasks. However, it is possible to use self-signed certificates in DSE.

These steps walk you through the general process to generate and distribute SSL certificates using OpenSSL and Java keytool. Use an intermediary certificate chain to securely implement SSL in a production environment, see the OpenSSL root CA instructions.

OpsCenter Lifecycle Manager can configure DataStax Enterprise clusters to use client-to-node and node-to-node encryption and automates the process of preparing server certificates. See Configuring SSL/TLS for DSE using LCM.

Prerequisites

Perform the following steps on a dedicated CA server which is fully encrypted and permanently isolated from the network. When using BYO CA, always create the root pair for certificate signing in a secure environment. Anybody with access to the root CA files can use it to sign certificates.

Note: DataStax recommends using a computer outside the DSE environment to generate and manage SSL certificates.

The Common Name (CN) that is used to generate the SSL certificate must match the DNS resolvable host name. Mismatches between the CN and node hostname cause an exception and the connection is refused.

Procedure

Skip to step 3 when using a third-party signed certificate or when adding a node using an existing rootCA.

BYO root CA only: create your own root CA for signing node certificates:

Create a directory for the CA and then change to that directory:
```
mkdir -p dse/root/ca
cd dse/root/ca
```
Note: Ensure that the root CA files created in these steps are secured on a fully isolated computer dedicated to CA certificate management.
Create a configuration file in the ca directory:
```
# gen_rootCa_cert.conf
[ req ]
distinguished_name	= req_distinguished_name
prompt				= no
output_password		= myPass
default_bits		= 2048

[ req_distinguished_name ]
C					= US
O					= org_name
OU					= cluster_name
CN					= rootCa
```
Where you define the variables for your environment as follows:
- gen_rootCa_cert.conf is the configuration file name
- myPass is the CA password
- US is the two character country code
- org_name is the name of your organization
- cluster_name is the name of your DataStax Enterprise cluster
Create a root pair.
```
openssl req -config gen_rootCa_cert.conf \
-new -x509 -nodes \
-subj /CN=rootCa/OU=cluster_name/O=DataStax/C=US/ \
-keyout rootCa.key \
-out rootCa.crt \
-days 365
```
The root pair, rootCa.key key file and rootCa.crt are created. These instructions are for development and test environments, for a production environment these files would be carefully secured as described in the OpenSSL documentation.

Verify the root certificate:

openssl x509 -in rootCa.crt -text -noout

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 14793138693831603662 (0xcd4bc943beeb35ce)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=datastax, OU=pw-j-dse, CN=rootCa
        Validity
            Not Before: Jan 23 20:15:06 2017 GMT
            Not After : Jan 23 20:15:06 2018 GMT
        Subject: C=US, O=datastax, OU=pw-j-dse, CN=rootCa
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d8:71:e0:51:07:ad:f1:f7:0b:4d:2c:10:4c:24:
                    19:9f:1f:d4:2a:a1:a6:89:3d:e1:12:81:3b:4d:bd:
                    2d:da:fb:9e:d5:c5:ba:ed:82:80:28:35:e5:00:86:
                    96:2b:67:18:37:c9:80:32:3e:40:0a:25:5d:c2:d5:
                    1c:bf:de:29:7a:fa:d6:32:20:35:39:03:e6:0a:35:
                    96:9d:8e:ca:88:b2:71:24:50:d2:94:1c:80:de:dd:
                    39:35:57:38:b2:09:39:ba:b3:9b:60:a1:5a:c7:f3:
                    04:35:73:f9:b6:05:1e:09:a2:e1:0e:1c:eb:6f:5e:
                    66:71:ec:38:08:99:6e:a3:d5:2a:0f:af:99:f5:19:
                    c0:6d:4d:b0:ae:0f:6e:7b:c9:78:7d:29:37:3c:3d:
                    38:7a:74:da:d1:16:38:5a:2b:f1:ac:a0:39:91:4a:
                    83:6f:1e:92:b5:66:fd:7f:5f:57:77:5f:c5:c6:ca:
                    23:63:95:d5:36:04:c2:c3:94:6f:2d:56:7e:96:4b:
                    e1:f2:ca:cd:4a:d6:9d:50:1a:5d:6e:1b:76:57:b4:
                    cd:a6:1a:6a:bb:82:d3:32:b4:b6:85:34:b1:d3:6c:
                    31:f7:a1:51:2e:1f:48:c7:c9:04:d2:c4:38:d7:84:
                    c8:cb:08:10:04:a8:a6:12:cf:48:54:88:b6:f7:bc:
                    f2:5d
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
         43:8d:98:8c:d7:26:52:41:ad:de:c9:80:8d:4f:d6:6e:21:69:
         81:7d:eb:af:93:6e:15:ad:9d:fe:ee:1a:60:d6:aa:92:86:a2:
         fd:e1:8f:95:b9:ee:db:59:63:fd:cd:05:72:63:d6:6b:14:cf:
         34:8c:15:cd:38:0a:ef:0d:41:de:9d:55:f2:2a:eb:1d:ca:44:
         21:f8:18:41:42:d9:e2:fb:c4:97:80:9c:ac:8b:61:d8:d9:33:
         38:9d:98:79:39:04:06:a8:b0:8e:e2:0e:49:5b:13:95:0b:42:
         2f:64:8c:9d:4a:6e:84:ca:40:26:7e:c8:a2:f3:e0:09:fc:9c:
         e8:a7:8a:6d:d2:cd:37:1f:0a:b8:61:c8:c3:f6:17:83:0f:24:
         0e:06:09:bc:73:09:32:70:f0:2f:9f:b1:7e:b8:ff:36:5c:3c:
         a9:28:69:58:fd:6b:55:2c:1f:8e:28:9c:8d:c9:37:66:9d:28:
         d7:4c:e5:fe:67:45:52:41:68:36:88:26:b1:95:f5:27:43:b3:
         1e:01:23:85:64:14:86:ff:b8:93:9e:06:78:ad:8b:2f:27:d8:
         35:06:49:37:d4:9f:d6:6f:a8:78:1f:b5:cf:96:2b:d7:da:02:
         2c:94:6f:1d:66:5c:e8:a6:a8:c9:e6:65:6a:6a:99:4a:61:a9:
         fe:7d:3e:c8

Create a single truststore:
```
keytool -importcert -file '../ca/rootCa.crt' \
-keystore dse-truststore.jks \
-storepass truststorePass \
-noprompt
```
Tip: Even when using a well-known certificate authority, DataStax recommends creating a truststore with the signing CA certificate (or certificate chain following the instructions from your CA).
The truststore contains a single entry. Verify the truststore using the following command:
```
keytool -list \
-keystore dse-truststore.jks \
-storepass truststorePass
```

Start here when using a third-party CA or when adding a node to an existing DSE environment with SSL enabled.

For each node in the cluster, create a keystore and key pair, and certificate signing request using FQDN of the node.
1. Create a directory to store the keystores and change to the directory:
```
mkdir -p dse/keystores
cd dse/keystores
```
2. For each node, generate a keystore with key pair:
```
keytool -genkeypair -keyalg RSA \
-alias node_name \
-keystore keystore_name.jks \
-storepass myKeyPass \
-keypass myKeyPass \
-validity 365 \
-keysize 2048 \
-dname "CN=host_name, OU=cluster_name, O=org_name, C=US"
```
  where the host_name is the FQDN (Fully Qualified Domain Name).
  Important:
  Use a DNS resolvable FQDN (Full Qualified Domain Name) for each node, to ensure the information you are using is correct run the following commands on each node:
  nslookup $(hostname --fqdn) && hostname --fqdn && hostname -i
  Server: 10.200.1.10 Address: 10.200.1.10#53 Name: node.example.com Address: 10.200.182.183 node.example.com 10.200.182.183
3. Verify each SSL keystore and key pair:
```
keytool -list -keystore keystore_name.jks -storepass myKeyPass
```
  Results for keystore with single entry with alias node1.
```
Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

node1, Jan 23, 2017, PrivateKeyEntry,
Certificate fingerprint (SHA1): 12:B7:45:AA:AD:F0:22:23:3F:13:FC:2C:3D:A4:4F:84:16:96:58:66
```
4. Generate a signing request from each keystore:
```
keytool -keystore keystore_name.jks \
-alias node_name \
-certreq -file signing_request.csr \
-keypass myKeyPass \
-storepass myKeyPass \
-dname "CN=host_name, OU=cluster_name, O=org_name, C=US"
```
  The certificate signing request file (signing_request.csr) is created. Repeat for each node, ensuring that the dname information matches the node information.
Sign the certificate signing request of each node:
- BYO root CA: Using the root CA created in step 1, sign each nodes certificate:
```
openssl x509 -req -CA '../ca/rootCa.crt' \
-CAkey '../ca/rootCa.key' \
-in node0.csr \
-out node0.crt_signed \
-days 365 \
-CAcreateserial \
-passin pass:myPass
```
  A signed certificate file is created, verify that was properly signed:
```
openssl verify -CAfile '../ca/rootCa.crt' node0.crt_signed
```
```
node0.crt_signed: OK
```
- Send the certificate signing request to a well-known CA for signing.
For each node in the cluster, import the signed certificates into the keystores:
1. Import the root certificate into each node's keystore:
```
keytool -keystore node0.keystore.jks \
-alias node_name \
-importcert -file '../ca/rootCa.crt' \
-noprompt  -keypass myKeyPass \
-storepass myKeyPass
```
  where the following must match the items created in the previous steps:
  - node0.keystore.jks - keystore created in 3.b
  - node_name is the alias used in 3.b, rootCa.
  - rootCa.crt - root certificate
  Warning: An error occurs, keytool error: java.lang.Exception: Failed to establish chain from reply, if the signed certificate for the node is imported before the root certificate.
2. Import the node's signed certificate into corresponding keystore:
```
keytool -keystore node0.keystore.jks \
-alias node_name \
-importcert -noprompt \
-file node0.crt_signed \
-keypass myKeyPass \
-storepass myKeyPass
```
  where the alias name must match the alias name used to generate the signing request in step 3.d.
  Confirmation of the installation appears, repeat both steps for each node's keystore:
```
Certificate reply was installed in keystore
```
Move the truststores and keystores to a computer with access to the DSE nodes and distribute to each node:
1. Create a directory for the certificates in the DSE configuration directory on each node:
```
mkdir -p dse/conf/certs
```
2. Copy the truststore to each node using a generic name:
```
scp dse-truststore.jks \
node0:dse/conf/certs/truststore.jks
```
  Using the same name and location on all nodes allows the same configuration for SSL in the cassandra.yaml.
3. Copy the corresponding keystore to each node using a generic name:
```
scp node0.keystore.jks \
node0:dse/conf/certs/keystore.jks
```
  Important: Be sure to copy the correct keystore to the correct nodes.