You must create an internal repository to upgrade Key Trustee KMS. For instructions on creating internal repositories (including Cloudera Manager, CDH, and Cloudera Navigator encryption components), see Creating and Using a Parcel Repository for Cloudera Manager if you are using parcels, or Creating and Using a Package Repository for Cloudera Manager if you are using packages.

Key Trustee KMS provides logic to detect and warn users about a potential problem where the GPG private keys have not been properly synchronized across all Key Trustee KMS HA hosts. If you have been running Key Trustee KMS on different hosts, and have not maintained private key synchronization, it is possible that the hosts may continue to operate and appear in a healthy state. However, when private keys are not synchronized between hosts, you can end up in a "split brain" scenario. In this scenario, the keys are actually only intermittently accessible, depending on which Key Trustee KMS host a client interacts with, because cryptographic key material encrypted by one Key Trustee KMS host cannot be decrypted by another. In the event of a catastrophic failure of one Key Trustee KMS host, any keys it has encrypted and any data encrypted by those keys will become inaccessible.

java.io.IOException: Unable to verify private key match between KMS hosts. Verify private key files have been synced
between all KMS hosts. Aborting to prevent data inconsistency.

To determine whether or not the Key Trustee KMS private keys are different, compare the MD5 hash of the private keys by executing the following command on each Key Trustee KMS host:

$ md5sum /var/lib/kms-keytrustee/keytrustee/.keytrustee/secring.gpg

  Warning: If you see the previously mentioned Java exception in the Key Trustee KMS logs after an upgrade, or independently verify that the GPG private keys do not match using the MD5 hash, do not attempt to synchronize existing keys. If you overwrite the private key and do not have a backup, any keys encrypted by that private key are permanently inaccessible, and any data encrypted by those keys is permanently irretrievable. If the private keys are preserved, the problem is recoverable and no data should be lost. Immediately back up all Key Trustee KMS hosts, and contact Cloudera Support for assistance correcting the issue.

  Important: Back up Key Trustee KMS before upgrading. See Backing Up and Restoring Key Trustee Server and Clients for instructions.

1. Go to Hosts > Parcels.
2. Click Configuration and add your internal repository to the Remote Parcel Repository URLs section. See Configuring the Cloudera Manager Server to Use the Parcel URL for Hosted Repositories for more information.
3. Click Save Changes.
4. Download, distribute, and activate the KEYTRUSTEE parcel for the version to which you are upgrading. See Parcels for detailed instructions on using parcels to install or upgrade components.
5. Restart the Key Trustee KMS service (Key Trustee KMS service > Actions > Restart).

1. After Setting Up an Internal Repository, configure the Key Trustee KMS host to use the repository. See Modifying Clients to Find the Repository for more information.
2. Add the CDH repository. See To add the CDH repository for instructions. If you want to create an internal CDH repository, see Creating a Local Yum Repository.
3. Upgrade the keytrustee-keyprovider package using the appropriate command for your operating system:
   • RHEL-compatible

     $ sudo yum install keytrustee-keyprovider

   • SLES

     $ sudo zypper install keytrustee-keyprovider

   • Ubuntu or Debian

     $ sudo apt-get install keytrustee-keyprovider

4. Restart the Key Trustee KMS service (Key Trustee KMS service > Actions > Restart).