Configuring SSL for Client-to-Node Connections

Client-to-node encryption protects in-flight data from client machines to a database cluster using SSL (Secure Sockets Layer) and establishes a secure channel between the client and the coordinator node.

On a DSE Search node, enabling SSL for the database automatically enables SSL in the DSE Search web.xml file and configures an SSL connector in Tomcat using the authentication or authorization filters. No changes are required for the web.xml or server.xml files.

If the TomcatSolrRunner does not find a connector in server.xml, it creates a default connector. The default connector binds to the native_transport_address.

The default location of the Tomcat server.xml file depends on the installation type:

Package installations: /etc/dse/tomcat/conf/server.xml
Tarball installations: <installation_location>/resources/tomcat/conf/server.xml

If you aren’t using the JCE Unlimited Strength Jurisdiction Policy, make sure that your ticket granting principal doesn’t use AES-256.

If your ticket granting principal 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

Starting in JDK 8u161, JCE Unlimited is enabled by default. See the release notes for JDK 8u161.

Complete the following procedure on every node in the cluster to configure SSL for client-to-node connections:

Create SSL certificates, keystores, and truststores. You can either create local keystore files or use a remote keystore provider.
Locate the cassandra.yaml configuration file. The location of this file depends on the type of installation:
- Package installations: /etc/dse/cassandra/cassandra.yaml
- Tarball installations: <installation_location>/resources/cassandra/conf/cassandra.yaml
Edit cassandra.yaml and make the following changes in the client_encryption_options to enable SSL:
1. Set enabled to true to enable SSL.
2. Set optional to false (default) to only allow SSL connections.
3. Set require_client_auth to true to require two-way host certificate validation.

Configure the keystore and truststore, depending on whether you are using local keystore files or a remote keystore provider. All settings are configured in the client_encryption_options section of cassandra.yaml.

Be aware that the store_type option is deprecated. Instead, use keystore_type and truststore_type.

For local files, use the following settings:

client_encryption_options:
    enabled: true
    optional: false
    keystore_type: JKS
    keystore: <path_to_keystore>
    keystore_password: <keystore_password>
    require_client_auth: true
    truststore_type: JKS
    truststore: <path_to_truststore>
    truststore_password: <truststore_password>
    protocol: ssl
    algorithm: SunX509
    cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA]

For a remote keystore provider, use the following settings:

client_encryption_options:
    enabled: true
    optional: false
    keystore_type: PKCS12
    require_client_auth: true
    truststore_type: PKCS12
    protocol: ssl
    algorithm: SunX509
    cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA]

Unused options can be blank or commented out. The remote keystore option requires installation of a provider. See Using a remote keystore provider.

enabled

Enables client-to-node encryption.

Default: false

optional

When optional is selected, both encrypted and unencrypted connections over native transport are allowed. That is a necessary transition state to facilitate enabling client to node encryption on live clusters without inducing an outage for existing unencrypted clients. Typically, once existing clients are migrated to encrypted connections, optional is unselected in order to enforce native transport encryption.

Default: false

keystore_type

Valid types are JKS (defeault), JCEKS, PKCS11, or PKCS12. For file-based keystores, use PKCS12.

DataStax supports PKCS11 as a keystore_type on nodes with cassandra or advanced workloads. The advanced workload support was added for DSE 6.8.2 and later. If PKCS11 is needed, in server_encryption_options or client_encryption_options, specify the keystore_type as PKCS11 and the keystore as NONE.

PKCS11 is not supported as a truststore_type.

keystore

Relative path from DSE installation directory or absolute path to the Java keystore (JKS) suitable for use with Java Secure Socket Extension (JSSE), which is the Java version of the Secure Sockets Layer (SSL), and Transport Layer Security (TLS) protocols. The keystore contains the private key used to encrypt outgoing messages.

Default: resources/dse/conf/.keystore

keystore_password

Password for the keystore.

Default: cassandra

require_client_auth

Enables certificate authentication for client-to-node encryption.

true: Require certificate authentication for client-to-node encryption. Client certificates must be present on all nodes in the cluster.
false (default): Do not require certificate authentication for client-to-node encryption.

truststore_type

Valid types are JKS (default), JCEKS, or PKCS12. For file-based truststores, use PKCS12. For important information about PKCS11 and PKCS12, see Using a remote keystore provider.

truststore

The relative path from the DSE installation directory or the absolute path to the truststore containing the trusted certificate for authenticating remote servers.

Truststore password and path are only required when require_client_auth is set to true.

Default: resources/dse/conf/.truststore

truststore_password

Password for the truststore. This must match the password used when generating the keystore and truststore.

Truststore password and path are only required when require_client_auth is set to true.

Default: cassandra

Save and close the cassandra.yaml file.
Complete a rolling DSE restart.

Configuring SSL for Client-to-Node Connections

See also

Was this helpful?

Give Feedback