Issues Fixed in Cloudera Navigator Key Trustee Server

The following sections describe issues fixed in each Cloudera Navigator Key Trustee Server release.

Issues Fixed in Cloudera Navigator Key Trustee Server 5.11.0

Key Trustee Server logs omit timestamps

The Key Trustee Server log entries do not include timestamps.

Issues Fixed in Cloudera Navigator Key Trustee Server 5.10.1

Key Trustee Server logs omit timestamps

The Key Trustee Server log entries do not include timestamps.

Issues Fixed in Cloudera Navigator Key Trustee Server 5.10.0

For new features in Key Trustee Server 5.10.0, see New Features and Changes in Cloudera Navigator Key Trustee Server.

Issues Fixed in Cloudera Navigator Key Trustee Server 5.9.0

For new features in Key Trustee Server 5.9.0, see New Features and Changes in Cloudera Navigator Key Trustee Server.

Issues Fixed in Cloudera Navigator Key Trustee Server 5.8.0

Key Trustee Server logs superfluous error during registration

When you register a client to the Key Trustee Server, the following error message appears in the Key Trustee Server log:
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/keytrustee/server/webapp.py", line 2151, in lookup
    return hkp.lookup(g.hkpdb, app.config['LOCAL_FINGERPRINT'])
  File "/usr/lib/python2.6/site-packages/keytrustee/server/hkp.py", line 72, in lookup
    raise wzex.BadRequest("Operation not specified.")
BadRequest: 400: Operation not specified.

Issues Fixed in Cloudera Navigator Key Trustee Server 5.7.0

Email messages from Key Trustee Server use hostname instead of fully qualified domain name

Email sent from Key Trustee Server includes a link that uses the Key Trustee Server short name instead of the fully qualified domain name.

Host Inspector displays the wrong version of Key Trustee Server

Host Inspector displays the wrong Key Trustee Server version, showing the Key Trustee KMS version instead.

Key Trustee Server supports weak RC4 ciphers for TLS

Key Trustee Server supports weak RC4 ciphers for TLS connections, potentially allowing clients to negotiate a weaker connection.

The ktadmin keyhsm command fails with M2Crypto error

Running the ktadmin keyhsm --server https://khsm01.example.com:9090 --trust command fails with the following error:

M2Crypto.X509.X509Error: 140405990356800:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: CERTIFICATE

Issues Fixed in Cloudera Navigator Key Trustee Server 5.5.2

Key Trustee Server with password-protected private key cannot communicate with Key HSM

If its private key is password-protected, Key Trustee Server cannot communicate with Key HSM.

Issues Fixed in Cloudera Navigator Key Trustee Server 5.5.0

Key Trustee Server missing from Components page

Key Trustee Server is not listed in the Components page (Hosts > Hostname > Components) of the host it is installed on.

Passive Database role fails to restart after enabling synchronous replication

After enabling synchronous replication, the Passive Database role fails to start when restarting the Key Trustee Server service in Cloudera Manager.

Key Trustee Server using CherryPy allows SSLv3

Key Trustee Server using CherryPy as the web backend allows SSLv3 connections, which are considered insecure.

Key Trustee Server sends wrong command in email notification

When you register a client, Key Trustee Server sends an email notification with a command to import the Key Trustee Server GPG key. The command uses the hkp protocol and port 80. The correct protocol is hkps and the correct port is 11371.

Enabling synchronous replication fails if python-ordereddict is not installed

On Key Trustee Server hosts where the python-ordereddict package is not installed, enabling synchronous replication fails, and the Passive Database role fails to start. The stderr.log file for the DB_ACTIVE-setup process (/var/run/cloudera-scm-agent/process/ID-keytrustee_server-DB_ACTIVE-setup/logs/stderr.log contains the following error:
Traceback (most recent call last):
  File "aux/prop2x.py", line 14, in <module>
    from ordereddict import OrderedDict
ImportError: No module named ordereddict

Key Trustee Server does not respond to requests

On systems with low entropy, local fingerprint generation fails during setup, but Cloudera Manager reports no issues with the Key Trustee Server service. Subsequent attempts to use Key Trustee Server fail with an error similar to the following in the Key Trustee Server log:
2015-06-03 11:44:17,232 - keytrustee.server.webapp - ERROR - 'None' is not a valid qualified fingerprint
Traceback (most recent call last):
  File "/opt/cloudera/parcels/KEYTRUSTEE_SERVER-5.4.0-1.keytrustee5.4.0.p0.204/lib/python2.6/
site-packages/keytrustee-5.4.0-py2.6.egg/keytrustee/server/webapp.py", line 1917, in index
    server.response = server.respond()
  File "/opt/cloudera/parcels/KEYTRUSTEE_SERVER-5.4.0-1.keytrustee5.4.0.p0.204/lib/python2.6/
site-packages/keytrustee-5.4.0-py2.6.egg/keytrustee/server/webapp.py", line 1783, in respond
    return Response(self.get_fingerprint(), **g.resp_kwargs)
  File "/opt/cloudera/parcels/KEYTRUSTEE_SERVER-5.4.0-1.keytrustee5.4.0.p0.204/lib/python2.6/
site-packages/keytrustee-5.4.0-py2.6.egg/keytrustee/server/webapp.py", line 1338, in get_fingerprint
    key_info = g.gpg.get_key_info(str(app.config['LOCAL_FINGERPRINT']))
  File "/opt/cloudera/parcels/KEYTRUSTEE_SERVER-5.4.0-1.keytrustee5.4.0.p0.204/lib/python2.6/
site-packages/keytrustee-5.4.0-py2.6.egg/keytrustee/gnupg.py", line 415, in get_key_info
    search_string = fp_or_id(fingerprint, keyid)
  File "/opt/cloudera/parcels/KEYTRUSTEE_SERVER-5.4.0-1.keytrustee5.4.0.p0.204/lib/python2.6/
site-packages/keytrustee-5.4.0-py2.6.egg/keytrustee/gnupg.py", line 817, in fp_or_id
    result = unqualified_fp(fingerprint)
  File "/opt/cloudera/parcels/KEYTRUSTEE_SERVER-5.4.0-1.keytrustee5.4.0.p0.204/lib/python2.6/
site-packages/keytrustee-5.4.0-py2.6.egg/keytrustee/gnupg.py", line 761, in unqualified_fp
    _, _, fp = read_qualified_fp(fp)
  File "/opt/cloudera/parcels/KEYTRUSTEE_SERVER-5.4.0-1.keytrustee5.4.0.p0.204/lib/python2.6/
site-packages/keytrustee-5.4.0-py2.6.egg/keytrustee/gnupg.py", line 770, in read_qualified_fp
    raise ValueError("'%s' is not a valid qualified fingerprint" % (s))
ValueError: 'None' is not a valid qualified fingerprint

Cannot register a client with Key Trustee Server after registering GPG public key

After creating an organization, the organization administrator receives a link to register a GPG key. If the administrator registers the GPG key before any clients are registered with the organization, all subsequent registrations with that organization fail.

Starting Key Trustee Server with --daemonize option fails

Starting Key Trustee Server with the command keytrustee-server start --daemonize fails with the following error:
2015-04-01 05:33:26,843 - cherrypy.error - ERROR - [01/Apr/2015:05:33:26] ENGINE Error in 'start' listener <bound method Daemonizer.start of <cherrypy.process.plugins.Daemonizer object at 0x1e71490>>
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/cherrypy/process/wspbus.py", line 197, in publish
    output.append(listener(*args, **kwargs))
  File "/usr/lib/python2.6/site-packages/cherrypy/process/plugins.py", line 380, in start
    si = open(self.stdin, "r")
IOError: [Errno 2] No such file or directory: '/tmp/stdout'

Starting Key Trustee Server when it is already running updates keytrustee.pid file

If you try to start Key Trustee Server when it is already running, the /var/lib/keytrustee/.keytrustee/keytrustee.pid file is updated with the new process ID (PID). The new process fails to start, but the keytrustee.pid retains the new PID, and service commands fail with the following error:
Traceback (most recent call last):
  File "/usr/bin/keytrustee-server", line 136, in <module>
    main()
  File "/usr/bin/keytrustee-server", line 131, in main
    status()
  File "/usr/bin/keytrustee-server", line 104, in status
    pid_file = ProcessIDInfo(ARGS.pidfile)
  File "/usr/lib/python2.6/site-packages/keytrustee/process.py", line 8, in __init__
    raise ex.KeytrusteeError('Invalid PID path: %s' % path)
keytrustee.exceptions.KeytrusteeError: Invalid PID path: /var/lib/keytrustee/.keytrustee/keytrustee.pid

Starting Key Trustee Server while the port is in use fails silently

If you try to start Key Trustee Server while the port is in use (for example, due to a stale process or another process using the port), the process appears to start successfully, but ends shortly after with no indication to the user. The Key Trustee Server log contains the following error:
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/cherrypy/process/wspbus.py", line 235, in start
    self.publish('start')
  File "/usr/lib/python2.6/site-packages/cherrypy/process/wspbus.py", line 215, in publish
    raise exc
ChannelFailures: IOError("Port 11371 not free on 'keytrustee01.example.com'",)

Starting Key Trustee Server as a user other than keytrustee fails

Starting Key Trustee Server as a user other than keytrustee (for example, as root or another super user) fails.

Issues Fixed in Cloudera Navigator Key Trustee Server 5.4.9

Cannot register a client with Key Trustee Server after registering GPG public key

After creating an organization, the organization administrator receives a link to register a GPG key. If the administrator registers the GPG key before any clients are registered with the organization, all subsequent registrations with that organization fail.

Issues Fixed in Cloudera Navigator Key Trustee Server 5.4.3

Key Trustee Server logs error GnuPG operation exited with return code=2

The Key Trustee Server log (keytrustee.log) includes error messages such as the following:
2014-12-30 04:23:22,166 - keytrustee.gnupg - ERROR - GnuPG operation exited with return code=2:
[GNUPG:] ENC_TO 9375BEFD0BEC8C12 1 0
[GNUPG:] GOOD_PASSPHRASE
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] PLAINTEXT 62 1419942201
[GNUPG:] PLAINTEXT_LENGTH 230
[GNUPG:] ERRSIG DF46C6427B4466F3 1 10 00 1419942201 9
[GNUPG:] NO_PUBKEY DF46C6427B4466F3
[GNUPG:] DECRYPTION_OKAY
[GNUPG:] END_DECRYPTION

Package conflict: python-jinja2

Installing or upgrading Key Trustee Server on RHEL fails on hosts where python-jinja2 is installed.

The keytrustee-orgtool add command fails with timeout: timed out error on CentOS 6.6

Adding an organization with the keytrustee-orgtool add command on CentOS 6.6 fails with the following error:
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib64/python2.6/threading.py", line 532, in __bootstrap_inner
    self.run()
  File "/usr/lib64/python2.6/threading.py", line 484, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.6/site-packages/keytrustee/server/util.py", line 363, in send_mail
    smtp = smtplib.SMTP('localhost', timeout=timeout)
  File "/usr/lib64/python2.6/smtplib.py", line 239, in __init__
    (code, msg) = self.connect(host, port)
  File "/usr/lib64/python2.6/smtplib.py", line 296, in connect
    (code, msg) = self.getreply()
  File "/usr/lib64/python2.6/smtplib.py", line 337, in getreply
    line = self.file.readline()
  File "/usr/lib64/python2.6/socket.py", line 450, in readline
    data = self._sock.recv(self._rbufsize)
timeout: timed out

Passive Database role sometimes fails to start when starting the Key Trustee Server service

Starting or restarting the Key Trustee Server service attempts to start the Active Database role and Passive Database role. If the Active Database has not completed starting up when the Passive Database attempts to start, the Passive Database fails to start.

For parcel-based installations, client and path environments must be manually configured

Users cannot use Key Trustee Server command-line utilities without configuring the path and setting environment variables.

Initializing high availability Key Trustee Servers fails if SSH communication fails

Initializing the active Key Trustee Server fails if the active Key Trustee Server cannot reach the passive Key Trustee Server over the default SSH port (22).

Enabling synchronous replication for high availability Key Trustee Servers fails

Running the ktadmin enable-synchronous-replication command does not properly configure synchronous replication in Key Trustee Server 5.4.0.

Issues Fixed in Cloudera Navigator Key Trustee Server 5.4.0

Cannot configure Key HSM after upgrade

After upgrading Key Trustee Server and Key HSM, the ktadmin keyhsm --server khsm01.example.com --trust command fails with the following error:
TypeError: coercing to Unicode: need string or buffer, NoneType found