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.


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.


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
              Version: 1 (0x0)
              Serial Number: 14793138693831603662 (0xcd4bc943beeb35ce)
          Signature Algorithm: sha256WithRSAEncryption
              Issuer: C=US, O=datastax, OU=pw-j-dse, CN=rootCa
                  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)
                      Exponent: 65537 (0x10001)
          Signature Algorithm: sha256WithRSAEncryption
  2. Create a single truststore:

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

    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

    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> \

      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> \

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

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2024 DataStax | Privacy policy | Terms of use

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,