Client-to-node encryption

Steps to encrypt data that is in flight from client machines to a database cluster using SSL.

Client-to-node encryption protects data in flight from client machines to a database cluster using SSL (Secure Sockets Layer). It establishes a secure channel between the client and the coordinator node. Unlike Kerberos, SSL is fully distributed and does not require setting up a shared authentication service. For information about generating SSL certificates, see Preparing server certificates.

DSE Search

When you enable SSL, the authentication/authorization filters are automatically enabled in the Solr web.xml file and an SSL connector in Tomcat is configured. You do not have to change your web.xml or server.xml files.

Note: If the TomcatSolrRunner doesn't find a connector in resources/tomcat/conf/server.xml it creates a default connector. The default connector binds to the rpc_address in cassandra.yaml.

To satisfy specific security requirements with SSL, you can change the IP address for client connections to DSE Search. For example, to isolate a subnet.

Procedure

All nodes requires relevant SSL certificates on all nodes. Perform these steps on each node.

Ensure that the Common Name (CN) that is used to generate the SSL certificate matches the DNS resolvable host name.
Mismatches between the CN and node hostname cause an exception and the connection is refused.

In the file, in the client_encryption_options section:

To enable encryption, set enabled to true.
Set the paths to your .keystore and .truststore files.
Provide the passwords that were used when generating the keystore and truststore.
To enable client certificate authentication, set require_client_auth to true.
For DSE Search nodes and DSE Analytics nodes with Spark: set the truststore entries.

client_encryption_options:
    enabled: true
    keystore: resources/dse/conf/.keystore  ## Path to your .keystore file
    keystore_password: keystore password  ## Password that you used to generate the keystore
    store_type: JKS
    truststore: resources/dse/conf/.truststore  ## Path to your .truststore
    truststore_password: truststore password  ## Password that you used to generate the truststore
    protocol: ssl
    require_client_auth: true
    cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA]

For information about using Kerberos with SSL, see Using Kerberos and SSL at the same time. To encrypt the truststore and keystore passwords with KMIP, see Configuring encryption using off-server encryption keys.

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

Package installations	/etc/dse/cassandra/cassandra.yaml
Tarball installations	`install_location`/resources/cassandra/conf/cassandra.yaml

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

Installer-Services	/etc/dse/dse.yaml
Package installations	/etc/dse/dse.yaml
Installer-No Services	`install_location`/resources/dse/conf/dse.yaml
Tarball installations	`install_location`/resources/dse/conf/dse.yaml

If you use strong cipher suites to ensure secure client-to-node communication, you must install JCE to ensure support for all encryption algorithms. Some of the cipher suites in the default set of server_encryption_options in cassandra.yaml are included only in the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. To ensure support for all encryption algorithms, install the JCE Unlimited Strength Jurisdiction Policy Files.
If you do not use the JCE Unlimited Strength Jurisdiction Policy, make sure that your ticket granting principal does not use AES-256.
If your ticket granting principle uses AES-256, you might see a warning like this in the logs:
```
WARN [StreamConnectionEstablisher:18] 2015-06-22 14:12:18,589 SSLFactory.java (line 162) Filtering out 
TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as it isnt supported by the socket
```