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

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

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

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, info@datastax.com