Reference: SSL instruction variables

The following variables are used throughout this section to demonstrate how to create local keystore files when configuring SSL on a two node, single datacenter cluster.

Anyone with access to the CA key and signing certificate can authorize hosts as the root certificate authority. Always secure these files.

Root certificate authority (CA) variables


Directory where the root certificate is created and stored. DataStax recommends securing this directory, ideally on a computer isolated from the network.


Root CA configuration file.

Distinguished Name (DN) properties


Title for the section containing the Distinguished Name (DN) properties for the CA.


Password for the generated file used to sign certificates.


Two letter country code, such as <US> for United States or <JP> for Japan. See Nations Online for a complete list of country codes.


Name of your organization.


Name of your DataStax Enterprise (DSE) cluster.


Common Name (CN) for the root CA.

Key and signing certificate


Key file for the root CA certificate.


Certificate used to sign (authorize) DSE node SSL certificates.

Truststore and keystore variables


Truststore that contains the root certificate.

Use the same truststore that contains the root certificate on all nodes.


Keystore for the individual node.

Default: none


Password used to protect the individual private key.

Default: none


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

Default: none


Password required to access the keystore.

Default: none


Location where the certificate file for each DSE node is created. Typically, SSL certificates and keys are generated on a secure system that is isolated from the network.


Fully Qualified Domain Name (FQDN) of the node, such as 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.


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:"

Certificate signing request (CSR) that is passed to the Certificate Authority (CA) to sign the certificate. The CSR typically includes the public key, plus associated metadata such as the Common Name (CN), Organization (O), Organization Unit (OU), and Country ©.


The signed certificate file to create, using the certificate signing request (CSR) (signing_request.csr) as the input file.


If using the domain name as the node_name and the node IP address as a subject alternative name (SAN), create a temporary configuration file and pass it in using the -extfile option. In the configuration file, use the subjectAltName parameter to specify the DNS and IP.

For example:


You can specify multiple SANs in the same configuration file:


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,