Using a remote keystore provider
Implement additional providers such as PKCS12.
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 |
DataStax Enterprise (DSE) database uses the Java Cryptography API (JCA) to implement SSL
providers. The JCA is a pluggable architecture that abstracts the actual cryptography
implementation from the algorithm requested. To support swapping out different
implementations, DSE database uses Cipher.getInstance("AES")
.
Introduction
The JCA architecture Provider class allows multiple implementations to register using a different service provider interface (SPI). Java comes with multiple providers and supports installation of additional providers, such as PKCS12.

- For PKCS12, in cassandra.yaml, the relevant property is
truststore_type
. DSE uses it to determine the desired SPI. The valid values fortruststore_type
are JKS, JCEKS, or PKCS12. The default is JKS, and the recommended setting for file-based truststores is PKCS12. However, there is a caveat and a workaround:Attention: Due to an OpenSSL issue, you cannot use a PKCS12 truststore that was generated via OpenSSL. For example, a truststore generated via the following command will not work with DSE:openssl pkcs12 -export -nokeys -out truststore.pfx -in intermediate.chain.pem
However, truststores generated via Java'skeytool
and then converted to PKCS12 work with DSE. Example:keytool -importcert -alias rootca -file rootca.pem -keystore truststore.jks
keytool -importcert -alias intermediate -file intermediate.pem -keystore truststore.jks
keytool -importkeystore -srckeystore truststore.jks -destkeystore truststore.pfx -deststoretype pkcs12
- For PKCS11, in cassandra.yaml, the relevant property is
keystore_type
. Valid types are JKS, JCEKS, PKCS11, PKCS12. The default is JKS, and the recommended setting for file-based keystores is PKCS12. If PKCS11 is desired, note the following:Attention: DataStax supports PKCS11 as akeystore_type
on nodes withcassandra
oradvanced
workloads. Thecassandra
workload support is specific to DSE 6.7.7 and later releases. Theadvanced
workload support is specific to DSE 6.7.9 and later. If PKCS11 is needed, inserver_encryption_options
orclient_encryption_options
, specify thekeystore_type
asPKCS11
and thekeystore
asNONE
. PKCS11 is not supported in DSE 6.0.x and 5.1.x releases. PKCS11 is not supported as atruststore_type.
- For cassandra.yaml reference descriptions, see the truststore_type and keystore_type settings.
Differences between PKCS11 and PKCS12
PKCS11 and PKCS12 are part of the RSA Public Key Cryptography Standards for storing private key and certificate information. If you haven't already, refer to the important caveats listed earlier in this topic.
PKCS12 is typically used to store private key and
certificate information on files. The default keystore type in Java is JKS, though you can
specify PKCS12 with the -deststoretype
option when creating a keystore with
keytool
. Be sure to read the notes above that
contain information about an openssl
bug, and the workaround via
keytool
for PKCS12 support.
PKCS11 provides an interface to connect with hardware keystore devices. This type of keystore can store private keys, secret keys, and certificates like PKCS12, but is designed for Hardware Storage Modules (HSM).
Installing additional providers
Install providers using the java.security
configuration that comes with
the JRE.
java.security
configuration file, which is located
in $JAVA_HOME/lib/security/java.security. For an
environment where PKCS11
is the keystore type and a Cassandra-only
workload, use:
security.provider.10=sun.security.pkcs11.SunPKCS11 path-to-pkcs11-provider-config-file
Example:
security.provider.10=sun.security.pkcs11.SunPKCS11 /opt/bar/cfg/pkcs11.cfg
For details, see the Oracle JDK 8 PKCS#11 Reference Guide.