[OPENDJ-1056] Secure listener should not be created if proper keying material is not available Created: 05/Jul/13  Updated: 08/Nov/19  Resolved: 03/Aug/15

Status: Done
Project: OpenDJ
Component/s: core server
Affects Version/s: 2.6.0, 2.5.0-Xpress1, 2.4.6, 2.4.5, 2.4.4, 2.4.3, 2.4.2, 2.4.1
Fix Version/s: 3.0.0

Type: Bug Priority: Major
Reporter: Bernhard Thalmayr Assignee: patrick diligent
Resolution: Fixed Votes: 2
Labels: release-notes

OpenDJ 2.5.0-Xpress1

Issue Links:
is backported by OPENDJ-1952 Backport OPENDJ-1056: secure listener... Done
is backported by OPENDJ-2221 Backport OPENDJ-1056: secure listener... Done
is related to OPENDJ-1959 Duplicated WARNING messages (and poss... Done
Dev Assignee: patrick diligent
Support Ticket IDs:
Backports: OPENDJ-1952 (2.6.4) OPENDJ-2221 (2.8.1)


If integration of a 3rd party CA signed cert is not done properly this can cause not that easy to troubleshoot SSL related issue.

Problem situation:

Keystore used by 'Key Management Provider', referenced by LDAPS connection handler did not include a 'PrivateKeyEntry' but 'trustedCertificateEntry' only due to whatever reason.

If OpenDJ is starting up the LDAPS connection handler is creating a socket just fine, however SSL connections fail as the keying material needed is missing on the server side.

Inexperienced troubleshooters do not get much info if

openssl s_client -connect OPENDJ_HOST:OPENDJ_LDAPS_PORT

just fails with a one-liner.

Comment by Bernhard Thalmayr [ 24/Jan/14 ]

it seems there could be different reasons, like missing alias in pkcs#12 file, incorrect password for keystore so that no proper keying material is not available to start secure conversations. Those situations are not easy to troubleshoot as they manifest in different erros. It would be great if the OpenDJ would not create the secure listener at all but log a proper error.

Comment by Ludovic Poitou [ 12/Jan/15 ]

How would the listener detect that the proper keying material is not available ?

Comment by patrick diligent [ 09/Apr/15 ]

The directory behaviour when the keystore is misconfigured is described below; the tested cases are :

  • Missing keystore file, - Corrupted keystore file, - Invalid key pin, - empty keystore, - keystore with invalid type (e.g no PrivateKeyEntry type)

1. Corrupted keystore, or invalid key pin

The directory server shuts down, and logs "[..... (An error occurred while attempting to initialize the SSL context for use in the LDAP Connection Handler: An error occurred while trying to load the keystore contents from file config/keystore: IOException(Keystore was tampered with, or password was incorrect) ...]

Applies also for a PKCS#12 key store

2. Keystore file missing

The directory starts successfully, but trace an error :

[09/Apr/2015:12:43:00 +1000] category=CORE severity=ERROR msgID=org.opends.messages.extension.45 msg=The keystore file config/keystore specified in attribute ds-cfg-key-store-file of configuration entry cn=JKS,cn=Key Manager Providers,cn=config does not exist.

This case is easily detected during the LDAP connection handler initialisation as the KeyProvider type falls back to a NullKeyProvider instance. This provider does nothing, and is of no help in handling the SSL handshake, so not sure what is the purpose here ?

3. When the entry is not a PrivateKeyEntry, or the alias is configured in the config (by default, it is not configured for the LDAPS connector) and that alias does not exist in the keystore

The directory starts successfully, and there are no error traces.

To make all cases consistent with case (1), that is, server fails to start in case of misconfiguration, the following changes could be made :

For case (2), throw exception if the provider is a NullKeyProvider (in LDAPConnectionHandler sslContext init)
For case (3), additional code should be added to inspect the keystore, and throw an exception for these case :

  • alias is named in config, and there is not corresponding entry with type PrivateKeyEntry
  • alias is not named in the config, and there is no entry with PrivateTypeEntry in the keystore

Throwing a DirectoryException within the LDAPConnectionHandler initialisation causes the server to shut down in error.

Whether the directory shuts down in case of security mis-configuration is also a point to review.

Note that it is fairly easy to mess-up the entry type in the keystore, this can be done by importing a certificate for an alias which has not be created initially by a -genkey command. As there is no associated key pair, the entry is created with type TrustedCertificateEntry relevant for a trust store.

Comment by Chris Ridd [ 21/Jul/15 ]

Fix is being revised.

Comment by Matthew Swift [ 07/Nov/19 ]

Moved to closed state because the fixVersion has already been released.

Generated at Tue Oct 27 06:46:48 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.