• Glossary
  • Support
  • Downloads
  • DataStax Home
Get Live Help
Expand All
Collapse All

Developing applications with DataStax drivers

    • Getting started
    • Best practices
    • Connecting to the database
      • Connecting to DataStax Astra databases
      • Authentication in DataStax drivers
      • Using SSL in DataStax drivers
      • Load balancing with DataStax drivers
      • Connection pooling
      • Retry policies
      • Reconnection policies
      • Execution profiles
    • Submitting queries
      • Working with multi-workload clusters
      • Using DSE Search with the DataStax drivers
      • Submitting DSE Graph queries with the DataStax drivers
      • Result paging with DataStax drivers
      • Synchronous and asynchronous query execution
      • Managing concurrency in asynchronous query execution
      • Speculative query execution
      • Query idempotence
      • Driver metrics
      • Object mappers in DSE drivers
      • Query timestamps
    • Error handling
      • Server errors
      • Client errors
    • Example applications
      • Connecting to Astra
      • Executing CQL statements
      • Executing bound statements
  • Developing applications with DataStax drivers
  • Connecting to the database
  • Using SSL in DataStax drivers

Using SSL in DataStax drivers

Prerequisites

cassandra.yaml

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

Package installations

/etc/dse/cassandra/cassandra.yaml

Tarball installations

<installation_location>/resources/cassandra/conf/cassandra.yaml

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:

  • No identity verification between the client and server.

  • The client verifies the identity of the server.

  • The server verifies the identity of the client.

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.

Table 1. SSL certificate instructions

C/C++

C#

Java

Node.js*

PHP

Python

Ruby

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.

Authentication in DataStax drivers Load balancing with DataStax drivers

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

© DataStax | Privacy policy | Terms of use

DataStax, Titan, and TitanDB are registered trademarks of DataStax, Inc. and its subsidiaries in the United States and/or other countries.

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.

landing_page landingpage