Bug 859858 - libldap does not load PEM certificate if certdb is used as TLS_CACERTDIR
libldap does not load PEM certificate if certdb is used as TLS_CACERTDIR
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openldap (Show other bugs)
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Jan Vcelak
David Spurek
: Regression
: 859582 (view as bug list)
Depends On: 857455
  Show dependency treegraph
Reported: 2012-09-24 04:30 EDT by Jan Vcelak
Modified: 2016-03-15 03:36 EDT (History)
8 users (show)

See Also:
Fixed In Version: openldap-2.4.23-31.el6
Doc Type: Bug Fix
Doc Text:
Cause: TLS is configured to use certificate from PEM file, while TLS_CACERTDIR is set to a Mozilla NSS certificate database. Consequence: The PEM certificate fails to load. Fix: Patch applied which makes the library to lookup the certificate in Mozilla NSS certificate database, and then fallback to PEM file if the certificate was not found. Result: The certificate from PEM file is successfully loaded under described conditions.
Story Points: ---
Clone Of: 857455
Last Closed: 2013-02-21 04:46:29 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jan Vcelak 2012-09-24 04:30:22 EDT
It has been reported that a very similar issue appears with older OpenLDAP:


With this version, the server will be hanging at startup instead of failing with "can't create ssl handle". But the cause and the fix are the same.

+++ This bug was initially created as a clone of Bug #857455 +++

Description of problem:

OpenLDAP library assumes wrongly that the specified certificate file is always in the Mozilla NSS certificate database, if the certificate database is set as TLS_CACERTDIR.

This might be a problem if the library consumer uses PEM certificates (TLS_CACERT, TLS_CERT, TLS_KEY) and TLS_CACERTDIR with Mozilla NSS database is set in system configuration file (ldap.conf).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. export LDAPTLS_CACERTDIR=/etc/openldap/certs
2. export LDAPTLS_CERT=/path/to/client.pem
3. export LDAPTLS_KEY=/path/to/client.pem
4. ldapsearch -Y EXTERNAL -H ldaps://server
Actual results:
TLS: certdb config: configDir='/etc/openldap/certs' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly
TLS: using moznss security dir /etc/openldap/certs prefix .
TLS: error: the certificate '/patk/to/client.pem' could not be found in the database - error -8174:security library: bad database..
TLS: error: could not initialize moznss security context - error -8174:security library: bad database.
TLS: can't create ssl handle.

Expected results:

Additional info:
Seems to be regression introduced by recent changes.

--- Additional comment from jvcelak@redhat.com on 2012-09-14 15:33:34 CEST ---

Created attachment 612876 [details]

Patch & upstream submission:

--- Additional comment from updates@fedoraproject.org on 2012-09-19 11:11:58 CEST ---

openldap-2.4.32-3.fc17 has been submitted as an update for Fedora 17.

--- Additional comment from updates@fedoraproject.org on 2012-09-19 11:13:28 CEST ---

openldap-2.4.32-3.fc18 has been submitted as an update for Fedora 18.

--- Additional comment from updates@fedoraproject.org on 2012-09-20 07:58:28 CEST ---

Package openldap-2.4.32-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openldap-2.4.32-3.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 2 Jan Vcelak 2012-09-24 05:00:41 EDT
*** Bug 859582 has been marked as a duplicate of this bug. ***
Comment 4 Jan Vcelak 2012-09-25 12:10:07 EDT
Resolved in: openldap-2.4.23-29.el6
Comment 7 Jan Vcelak 2012-10-31 08:19:09 EDT
Really resolved in: openldap-2.4.23-31.el6
Comment 11 errata-xmlrpc 2013-02-21 04:46:29 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.