Using SSL in DataStax drivers



The location of the cassandra.yaml file depends on the type of installation:

Package installations


Tarball installations


Configuration, Verification, and Workflow

DSE drivers support SSL-encrypted connections between the driver and server.

By default Apache Cassandra™ and DataStax Enterprise (DSE) are configured to communicate with clients using an unencrypted binary protocol. This is convenient for getting started but is usually not suitable for production environments, especially those with clients communicating with Cassandra or DSE over the public internet.

SSL in Cassandra and DSE can be configured different ways depending on the security requirements of the deployment. All configurations result in encrypted communication between the client and server.

SSL allows for different levels of identity verification:

A typical SSL workflow consists of the following stages:

  1. The client opens a TCP connection to the server on the configured SSL port.

  2. An SSL handshake is initialized by the server, sending its public key (or certificate) to the client.

  3. The client uses that public key certificate to generate an encrypted session key and sends it back to the server.

  4. The server decrypts the message using its private key and retrieves the session key.

  5. All communication from that point on is encrypted using that session key.

SSL certificate instructions








No identity verification

Clients with DataStax drivers communicating securely with Cassandra or DSE servers should validate the server’s identity. While most drivers support creating SSL connections to the server without identity verification, it is not recommended for production deployments.

When a secure browser contacts a web server, the browser verifies the identity of the server before sending it requests in case an attacker is masquerading as the web server. Secure communication to a bad actor defeats the purpose of configuring secure communication between the browser and web server in the first place.

Client verifies server

To verify the identity of a server, the driver must be configured with a list of trusted certificate authorities (CAs). When the driver receives the server’s SSL certificate during the SSL handshake, it checks that the certificate was signed by one of the registered CAs. If the certificate was not signed by a registered CA, the client checks that the signer was signed by one of the registered CAs. It continues through the signers until it finds one that is in the client’s list of trusted CAs.

If the client does not find a registered CA, identify verification fails.

Server verifies client

A server is configured to verify the identity of a client by setting the require_client_auth to true under client_encryption_options in cassandra.yaml. This scenario requires clients be configured with their own certificates to send to the server upon request during the SSL handshake.

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,