Known Issues in Cloudera Navigator 6.3.0 Encryption

Known Issues in Cloudera Navigator Key Trustee Server 6.1.0

Additional Key Trustee Server process appears after key creation when passive database is stopped

If a key is created while the passive Key Trustee Server database is down, the key creation will fail with the message, "Database write timed out." In this case, even after the passive database comes up, a hanging Key Trustee Server process thread may remain on the system attempting to complete the write. To view which Key Trustee Server processes are running, enter:
ps -ef | grep keytrustee | grep -v postgres
In normal operations there should be only one Key Trustee Server process running.

Affected Version: 6.0.0, 6.1.0

Cloudera Bug: KT-6684

Workaround: These extra Key Trustee Server processes do not cause any errors with the Key Trustee Server, but they will not be cleaned up properly when the Key Trustee Server is shut down. To fully shut down the Key Trustee Server when there are extra processes running, stop the Key Trustee Server service, and then kill any remaining processes.

Key Trustee Server active database setup fails when command line configuration specifies non-default database port

If the Key Trustee Server is configured from the command line to use a non-default database port (the default port is 11381), then when the Key Trustee Server service is added to Cloudera Manager, the first database startup fails.

Affected Version: 6.0.0, 6.1.0

Cloudera Bug: KT-6238

Workaround:
  1. Log in to the Key Trustee Server and manually stop/start the databases:
    service keytrustee-db stop
    Make sure that the postmaster.pid file, which is located in the database directory, no longer exists. If necessary, replace /var/lib/keytrustee/db in the following command with the appropriate database directory for your system:
    # ls /var/lib/keytrustee/db/postmaster.pid
    If postmaster.pid has not been cleaned up, then use the pg_ctl utility to stop the database directly:
    # pg_ctl stop
  2. Return to the Cloudera Manager home page where the Key Trustee Server service is listed.
  3. Go into the Key Trustee Server service configuration and for Key Trustee Server Database Port, specify the port that was configured during the command line configuration.
  4. Redeploy the Key Trustee Server configuration and restart the service.

Key Trustee KMS cannot connect to Key Trustee Server using TLS versions other than 1.0 on JDK 7

If you have configured Key Trustee Server to use a TLS version other than 1.0, Key Trustee KMS fails to connect to Key Trustee Server, and key operations fail when using JDK 7.

Workaround: Use TLS version 1.0 only, or JDK 8.

Key Trustee Server cannot use TLS version 1.2 on RHEL 6

Configuring Key Trustee Server to use TLS version 1.2 causes Key Trustee Server to be unable to start.

Workaround: Use your operating system package manager to upgrade the pyOpenSSL package to version 1.4 or higher, or do not configure Key Trustee Server to use TLS version 1.2.

Key Trustee Server PKCS8 private key cannot communicate with Key HSM

If its private key is in PKCS8 format, Key Trustee Server cannot communicate with Key HSM.

Affected Version: 6.0.0, 6.1.0

Cloudera Bug: KT-3172

Workaround: Convert the Key Trustee Server private key to raw RSA format.

Known Issues in Cloudera Navigator Key HSM 6.3.0

Thales Key HSM won't work with OpenJDK 11

Thales Key HSM is unsupported because the Thales client Java libraries do not support Java 11.

Affected Version: 6.3.0

Cloudera Bug: KT-6854

Workaround: None.

Roll key command throws an exception and cannot retrieve metadata for key

When using Key Trustee KMS with Key Trustee Server and Key HSM (backed by an HSM device), if there is significant (> 15 ms ping time) network latency between the Key Trustee Server and the HSM device, then EDEK generation errors can occur during the roll key operation. These errors manifest in the KMS log as errors on the generateEncryptedKey operation. The KMS will recover from these errors on its own, but they may represent a nuisance to the operator.

Affected Version: 6.0.0, 6.1.0, 6.2.0, 6.3.0

Cloudera Bug: KT-5646

Workaround: When these errors occur, you can use the hadoop key list -metadata command to confirm whether or not the key roll was successful, despite the error condition.

KeySecure HSM not supported

The KeySecure HSM is not supported in this release.

Affected Version: 6.0.0, 6.1.0, 6.2.0, 6.3.0

Cloudera Bug: KT-6001

Workaround: None.

Key HSM Luna setup not showing the correct login status

When running the keyhsm setup luna command, you are prompted for the Luna HSM slot number and login password. Key HSM then attempts to log into the Luna HSM to verify these settings are correct. In some circumstances, the setup script reports that the login was successful, even if it failed.

Affected Version: 6.0.0, 6.1.0, 6.2.0, 6.3.0

Cloudera Bug: KT-6623

Workaround: Any incorrect settings will cause the Key HSM service to throw an exception upon startup and exit. If the Key HSM service does not start correctly, check the log for the message: "Unable to sign into Luna HSM server. Please rerun application with 'setup' option to configure password." If this message appears, re-run the keyhsm setup luna command, and enter the correct slot number and login password.

Known Issues in Cloudera Navigator Key Trustee KMS 6.3.0

The Key Trustee KMS service fails to start if the Trust Store is configured without also configuring the Keystore

If you configure the Key Trustee KMS service Key Management Server Proxy TLS/SSL Certificate Trust Store File and Key Management Server Proxy TLS/SSL Certificate Trust Store Password parameters without also configuring the Key Management Server Proxy TLS/SSL Server JKS Keystore File Location and Key Management Server Proxy TLS/SSL Server JKS Keystore File Password parameters, the Key Trustee KMS service does not start.

Workaround: Configure all Trust Store and Keystore parameters.

Key Trustee KMS backup script fails if PostgreSQL versions lower than 9.3 are installed

If PostgreSQL versions lower than 9.3 are installed on the Key Trustee KMS host, the ktbackup.sh script fails with an error similar to the following:

pg_dump: server version: 9.3.11; pg_dump version: 9.2.14
pg_dump: aborting because of server version mismatch 

Workaround: Uninstall the lower PostgreSQL version.

Known Issues in Cloudera Navigator HSM KMS 6.3.0

Encryption zone key is not deleted after migrating from Key Trustee KMS to HSM KMS

After migrating keys from the Key Trustee KMS to the HSM KMS, the HSM KMS service should be restarted. Until it is restarted, any keys that are deleted after the migration may still be cached. If a deleted key is cached, then the data encrypted with that key can still be accessed even though the key has been deleted.

Affected Version: 6.0.0, 6.1.0, 6.2.0, 6.3.0

Cloudera Bug: KT-6434

Workaround: Restart the HSM KMS service after the key migration is complete.

Known Issues in Cloudera Navigator Encrypt 6.2.0

Navigator Encrypt cannot create an ACL when Key Trustee Server is down

Navigator Encrypt cannot create new ACLs when the Key Trustee Server is down. Navigator Encrypt will attempt to verify the master key with the Key Trustee Server when adding ACLs, even if the master key should already have been cached on the local system. If it can't communicate with the Key Trustee Server, the add ACL request will fail.

Affected Version: 6.1.0, 6.2.0

Cloudera Bug: KT-6390

Workaround: Make sure the Key Trustee Server is running before making modifications to Navigator Encrypt ACLs.

Issue with navencrypt-mount service status message

Affected Version: 6.0.0, 6.1.0, 6.2.0

Cloudera Bug: KT-6309

On RHEL 7, the service navencrypt-mount stop command might return a successful exit status message, even if there was a problem stopping Navigator Encrypt. This is not an issue with the navencrypt-mount service command; rather, it is a problem with the message output.

You can verify that navencrypt-mount stopped successfully by checking for the presence of the navencryptfs module in the lsmod output:
# lsmod | grep navencrypt
navencryptfs 101407 0
Alternatively, you can verify that the navencrypt mount points successfully dismounted by checking the output of the df or mount commands.

Workaround: None.