Using a remote keystore provider
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.
There are a few important points to consider regarding PKCS12 and PKCS11 support:
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
* For PKCS12, in cassandra.yaml, the relevant property is truststore_type.
DSE uses it to determine the desired SPI.
The valid values for truststore_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:
|
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: However, truststores generated via Java’s |
-
For
PKCS11, incassandra.yaml, the relevant property iskeystore_type. Valid types areJKS,JCEKS,PKCS11,PKCS12. The default isJKS, and the recommended setting for file-based keystores isPKCS12. IfPKCS11is desired, note the following:DataStax supports PKCS11 as a
keystore_typeon nodes withcassandraoradvancedworkloads. Theadvancedworkload support was added for DSE 6.8.2 and later. IfPKCS11is needed, inserver_encryption_optionsorclient_encryption_options, specify thekeystore_typeasPKCS11and thekeystoreasNONE.PKCS11is not supported as atruststore_type. -
For
cassandra.yamlreference descriptions, see the https://docs.datastax.com/en/dse/6.8/dse-admin/datastax_enterprise/config/configCassandra_yaml.html#configCassandra_yamlserverSsltruststore_type[truststore_type] and https://docs.datastax.com/en/dse/6.8/dse-admin/datastax_enterprise/config/configCassandra_yaml.html#configCassandra_yamlserverSslStoreType[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.
Review the important caveats listed earlier in this topic, if you have not already done so.
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.
|
For more detailed instructions, see How to implement a Provider (Oracle). |
Add the location to the 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.cfgFor details, see the Oracle JDK 8 PKCS#11 Reference Guide.
