Install and configure additional required components

Use the following steps to install additional required components for FIPS.

Default Truststore Behavior in FIPS Mode

When Cloudera Manager runs in FIPS-enabled mode with the default keystore type set to BCFKS in java.security, Cloudera Manager does not read from the JVM’s default truststore (cacerts).

Why Cloudera Manager does not use cacerts in the FIPS mode

In standard (non-FIPS) mode, Cloudera Manager relies on the JVM’s default cacerts truststore, which is in JKS format. This allows Cloudera Manager to automatically trust the default CA certificates shipped with the JDK and establish secure connections to external endpoints such as S3 or Cloudera repositories.
In FIPS mode, only FIPS-compliant keystore formats (such as BCFKS) are permitted. Because the default cacerts is in JKS format, Cloudera Manager skips loading it to prevent startup failures and instead uses the Cloudera Manager-provided truststore exclusively. This ensures consistent and reliable operation under FIPS compliance, but means that Cloudera Manager does not automatically trust certificates present only in the JVM's default cacerts.

As a result, connections to certain external endpoints (for example, public cloud services, S3, Cloudera download URLs) might fail unless their certificates are also present in the Cloudera Manager-provided truststore.
If Cloudera Manager attempts to load the JKS-formatted cacerts file while running in FIPS mode, it will fail the operation.

Preserving the default JVM truststore behavior in FIPS mode

If you want Cloudera Manager to continue trusting the same set of CA certificates that the JVM ships with (cacerts), you can explicitly configure a BCFKS-converted truststore by performing the following steps:

Locate the existing JVM cacerts file by running the following command:
```
$JAVA_HOME/lib/security/cacerts
```
The default password is usually changeit.
Create a backup copy of the file by running the following command:
```
cp $JAVA_HOME/lib/security/cacerts /tmp/cacerts.original
```

Convert it to BCFKS format by running the following command:

$JAVA_HOME/bin/keytool -importkeystore \
  -srckeystore $JAVA_HOME/lib/security/cacerts \
  -srcstoretype JKS \
  -srcstorepass changeit \
  -destkeystore $JAVA_HOME/lib/security/cacerts.bcfks \
  -deststoretype BCFKS \
  -deststorepass changeit \
  --provider com.safelogic.cryptocomply.jcajce.provider.CryptoComplyFipsProvider \ 
  --providerpath /path/to/ccj/fips/jar

Use the same value for providerpath as the one provided in /etc/default/cloudera-scm-server for -Dcom.cloudera.cloudera.cmf.fipsMode.jdk11plus.ccj.jar.path.

Replace the old cacerts with the converted one by running the following command:
```
mv cacerts.bcfks cacerts
```
Now, the file name remains cacerts, but the format inside is BCFKS.

Configure the Cloudera Manager Truststore

You must ensure Cloudera Manager correctly identifies your truststore and password. While Cloudera Manager attempts to use default paths, you must manually configure the settings if you use non-default locations or passwords.

Identify your truststore requirements: Determine if you are using the default system truststore or a custom file (for example, a .bcfks or .jks file in a specific directory).
Access the configuration file: Open /etc/default/cloudera-scm-server on the Cloudera Manager Server host.
Define the Java options: Add or update the CMF_JAVA_OPTS variable to explicitly define the path, type, and password.

Example Configuration:

Run the following command or manually append the flags to the file:

export CMF_JAVA_OPTS="$CMF_JAVA_OPTS \
                      -Djavax.net.ssl.trustStore=/path/to/truststore.file \
                      -Djavax.net.ssl.trustStoreType=BCFKS \
                      -Djavax.net.ssl.trustStorePassword=your_password"

Table 1. Usage Scenarios
Configuration Type	Action Required
Default Path & Password	Cloudera Manager typically detects the system `cacerts` automatically; however, explicitly defining it in `CMF_JAVA_OPTS` prevents resolution errors during upgrades.
Non-Default Path	You must set `-Djavax.net.ssl.trustStore` to the absolute path of your specific certificate file.
Non-Default Password	You must include `-Djavax.net.ssl.trustStorePassword` to ensure Cloudera Manager can decrypt and read the certificates.

Restart Cloudera Manager Server to apply the changes:
```
sudo systemctl restart cloudera-scm-server
```

important

This setup preserves the same certificates as the JDK’s default cacerts, but in a FIPS-compliant format.
If necessary, you can add additional certificates (for example, cloud provider roots) to this BCFKS truststore.
If you do not configure this, Cloudera Manager will only use the Cloudera Manager-provided truststore, and some external connections might fail.
Be aware that setting javax.net.ssl.trustStorePassword makes the truststore password available as a JVM-wide system property. This means the password is visible to all code running inside the Cloudera Manager JVM.

When Java code needs to open a secure connection (TLS/SSL) and does not explicitly say which truststore/keystore to use, the JVM falls back to its default SSLContext.

So, if you set the above configurations at the JVM level, all code using the default SSLContext picks them up automatically. Unlike javax.net.ssl.trustStore and javax.net.ssl.trustStoreType, which only specify the truststore file and format, the password property also exposes a sensitive secret to the entire JVM process.

Perform the Additional Steps for Apache Ranger.
Add Ranger to the Shadow group.
```
usermod -a -G shadow ranger
```
Install and Configure TLS either automatically or manually.
If you are using Auto-TLS, see:
- Use case 1: Use Cloudera Manager to generate an internal CA and corresponding certificates
- Use case 2: Use an existing Certificate Authority
If you are manually configuring TLS, see:
- Manually Configuring TLS Encryption for Cloudera Manager
note
Additional manual TLS configuration steps may be required for stack components.
Generate certificates in BCFKS format

The standard keytool utility distributed with the JDK can generate BCFKS formatted keystores using the CCJ security provider. When the CCJ security provider is statically installed into the JDK as previously described, there is no need to pass the keytool utility the -providerpath path/to/ccj-3.0.2.1.jar or -providerclass com.safelogic.cryptocomply.jcajce.provider.ProvBCFKS arguments. It is only necessary to pass BCFKS as the storetype for the keytool operation being invoked.

For example, keytool -importkeystore can be used to import a PKCS12 keystore into a BCFKS keystore:
```
keytool \
    -importkeystore -v \
    -srckeystore <pkcs12_keystore_file> \
    -srcstoretype PKCS12 \
    -srcstorepass <pkcs12_pass> \
    -destkeystore <bcfks_keystore_file> \
    -deststoretype BCFKS \
    -deststorepass <bcfks_keystore_pass> \
    -destkeypass <bcfks_key_pass>
```
Systems administrators and other platform implementers should consult their organization’s information systems security managers for the correct procedures for generating keypairs and requesting signing of x509 certificates. The Cloudera requires the private key and signed certificate in both PEM encoded and BCFKS keystore format. The steps to accomplish this task might look similar to the following:
1. openssl genpkey
2. openssl req
3. Have the CA sign the CSR.
4. Import the private key and signed certificate into a PKCS12 keystore:
```
openssl pkcs12
```
5. Import the PKCS12 keystore into a BCFKS keystore:
```
keytool -importkeystore
```
Enable Kerberos authentication using the Cloudera Manager Kerberos wizard.
Set the kdc_timeout value in the krb5.conf file to a high enough setting to avoid client timeout errors while running queries.
1. Open the /etc/krb5.conf file with a text editor.
2. Under [libdefaults], set the kdc_timeout value to a minimum of 5000 (5 seconds).
Install Apache Knox. See Installing Apache Knox.
Install Ranger KMS.
As Ranger KMS KTS and Key Trustee Server are not supported anymore, you need to migrate your encryption keys from Ranger KMS KTS and Key Trustee Server to Ranger KMS. For more information, see Key migration in UCL.
note
Ranger KMS uses the PBEWithMD5AndTripleDES algorithm for key encryption, which is not FIPS-compliant. Hence, for FIPS-enabled clusters, the PBKDF2WithHmacSHA256 algorithm is used, which is FIPS-compliant. The existing keys have to be re-encrypted. The re-encryption process is as follows:
1. Decrypt the existing keys using the older PBEWithMD5AndTripleDES algorithm and retrieve the key material.
2. Then, encrypt the retrieved key material using the FIPS-compliant algorithm, PBKDF2WithHmacSHA256.
3. Finally store it in the service DB.
To decrypt the existing keys, the old PBEWithMD5AndTripleDES algorithm and the corresponding SunJCE provider are needed. After re-encryption using the FIPS-compliant algorithm, the older algorithm and the corresponding provider can be removed. This re-encryption happens when the Ranger KMS process starts.
Configure HDFS Transparent Data Encryption with Ranger KMS.