Known Issues and Workarounds in Cloudera Navigator Key Trustee Server

Key version information may not be reported correctly by Hadoop key list -metadata operation after key roll.

After the key roll operation, the key's version remains the same.

Workaround: None

Key description is not synchronized with the second metastore

If the description option is specified as the argument in a Hadoop key create command, then the description information is stored only on the KMS instance that responds to the create request. The description metadata is not synchronized to the other KMS instances in the role group. This does not affect normal key operations.

Workaround: Use the -provider argument on the key list operation to target key queries to a specific KMS instance.

HSM KMS Luna may need to be restarted if inactive for extended period

If Hadoop key operations return com.safenetinc.luna.exception.LunaCryptokiException after the KMS has been running without activity for an extended period time, the Luna session may have been dropped.

Workaround: Restart the KMS service.

Creating multiple instances of HSM KMS on the same host and port causes an error upon delete

Creating a KMS role instance on a host that previously hosted a KMS role instance in the same role group that had its data directories deleted results in errors when attempting to run Hadoop key delete operations.

Workaround: This workaround requires the assistance of Cloudera support; request assistance with issue KT-4992

Incorrect status for "Restart stale services" step in HDFS encryption wizard post-service installation

There are times when completion of the HDFS Encryption Wizard does not show an active "Restart stale services and redeploy client configuration" link.

Workaround: Refresh the page and the link should become active.

The encryption wizard continues to fail if there is a failure during initial configuration run

The encryption wizard continues to fail if there was a failure during the initial run configuring HSM KMS.

Workaround: Open Cloudera Manager in another browser tab, and manually stop the installed KMS by clicking the arrow next to the KMS and selecting Stop. Then retry the installation in the new tab after correcting the cause of the install failure.

The HSM KMS trust store password is visible in logs

The KMS trust store password may be displayed in some process logs on the KMS hosts. While the trust store password is not considered sensitive, some customers set the trust store password to the same value as the key store password, which is sensitive.

Workaround: Ensure that the trust store password differs from other sensitive passwords.

Before installing the Thales backed HSM KMS, you must add the KMS user to the nfast group

After installation of the Thales HSM client, and before installing Navigator HSM KMS backed by Thales HSM, you must add the KMS user to the nfast group..

Workaround: Run the following command to manually add the KMS user to the nfast group:usermod -a -G nfast kms

Navigator Key HSM may become unresponsive when there are network delays or connection issues with the HSM

This issue manifests itself as job failures within CDH. To verify that this issue is the source of the failed CDH jobs and that Key HSM has become unresponsive log into the Key HSM server and look at the log file in /var/log/keyhsm/. If no new entries are being written to the log file while key requests are being made, e.g. CDH jobs continue to retry, then follow the directions in the Workaround section.

Workaround: If threads accumulate and Navigator Key HSM has become unresponsive then restart Key HSM by executing the following commands:
$ sudo service keyhsm shutdown
$ sudo service keyhsm start

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.

Upgraded passive Key Trustee Server fails to start due to incorrect ownership of recovery.conf

Passive Key Trustee Servers upgraded from Key Trustee Server 3.8.x or lower fail to start with the following error:
WARNING:root:stdout pg_basebackup: directory "/var/lib/pgsql/9.3/keytrustee" exists but is not empty
Traceback (most recent call last):
  File "/usr/bin/ktadmin", line 484, in <module>
  File "/usr/bin/ktadmin", line 473, in main
  File "/usr/bin/ktadmin", line 349, in init_slave
    pgsetup.base_backup(ARGS.pg_rootdir, ARGS.master, PKG, run_as=ARGS.postgres_user)
  File "/usr/lib/python2.6/site-packages/keytrustee/server/setup/", line 206, in base_backup
    run([pg_basebackup, '-D', dest, '--host=%s' % master_ip, '--port=%d' % port, '--username=%s' % db_user], run_as=run_as)
  File "/usr/lib/python2.6/site-packages/keytrustee/", line 145, in run
    raise subprocess.CalledProcessError(p.returncode, cmd)
subprocess.CalledProcessError: Command '['/usr/pgsql-9.3/bin/pg_basebackup', '-D', '/var/lib/pgsql/9.3/keytrustee', '', '--port=5432', '--username=keytrustee']' returned non-zero exit status 1
Workaround: Change the owner and group of /var/lib/pgsql/9.3/keytrustee/recovery.conf to postgres:
$ sudo chown postgres:postgres /var/lib/pgsql/9.3/keytrustee/recovery.conf

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.

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

Key Trustee Server 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 Server host, the 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.

Key migration fails when password-protected certificates are stored in a non-default location

Key migration from Key Trustee Server to Key HSM fails when using password-protected certificates in a non-default location.

Workaround: Use the --passphrase option with the ktadmin keyhsm command to prompt for the password. See Integrating Key HSM with Key Trustee Server for more information.