Setting up SSL certificates

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.

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.

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.

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

    1. Create a directory for the CA and then change to that directory:

      mkdir -p dse/root/ca
cd dse/root/ca

      Ensure that the root CA files created in these steps are secured on a fully isolated computer dedicated to CA certificate management.

    2. 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

    3. 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.

    4. 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

  2. Create a single truststore:

    keytool -importcert -file '../ca/rootCa.crt' \
-keystore dse-truststore.jks \
-storepass <truststorePass> \
-noprompt

    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.

  1. 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).

      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.

  2. 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.

  3. 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

        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

  4. 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

      Be sure to copy the correct keystore to the correct nodes.

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2025 DataStax | Privacy policy | Terms of use | Manage Privacy Choices

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: +1 (650) 389-6000, info@datastax.com