RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 859858 - libldap does not load PEM certificate if certdb is used as TLS_CACERTDIR
Summary: libldap does not load PEM certificate if certdb is used as TLS_CACERTDIR
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openldap
Version: 6.5
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Jan Vcelak
QA Contact: David Spurek
URL:
Whiteboard:
: 859582 (view as bug list)
Depends On: 857455
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-24 08:30 UTC by Jan Vcelak
Modified: 2016-03-15 07:36 UTC (History)
8 users (show)

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.
Clone Of: 857455
Environment:
Last Closed: 2013-02-21 09:46:29 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0364 0 normal SHIPPED_LIVE openldap bug fix and enhancement update 2013-02-20 20:52:54 UTC

Description Jan Vcelak 2012-09-24 08:30:22 UTC 
It has been reported that a very similar issue appears with older OpenLDAP:

openldap-2.4.23-26.el6_3.2

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):
openldap-2.4.32-2.fc17


How reproducible:
always


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:
success


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

--- Additional comment from jvcelak on 2012-09-14 15:33:34 CEST ---

Created attachment 612876 [details]
patch

Patch & upstream submission:
http://www.openldap.org/its/index.cgi?findid=7389

--- Additional comment from updates on 2012-09-19 11:11:58 CEST ---

openldap-2.4.32-3.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/openldap-2.4.32-3.fc17

--- Additional comment from updates on 2012-09-19 11:13:28 CEST ---

openldap-2.4.32-3.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/openldap-2.4.32-3.fc18

--- Additional comment from updates 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:
https://admin.fedoraproject.org/updates/FEDORA-2012-14390/openldap-2.4.32-3.fc18
then log in and leave karma (feedback).
Comment 2 Jan Vcelak 2012-09-24 09:00:41 UTC 
*** Bug 859582 has been marked as a duplicate of this bug. ***
Comment 4 Jan Vcelak 2012-09-25 16:10:07 UTC 
Resolved in: openldap-2.4.23-29.el6
Comment 7 Jan Vcelak 2012-10-31 12:19:09 UTC 
Really resolved in: openldap-2.4.23-31.el6
Comment 11 errata-xmlrpc 2013-02-21 09:46:29 UTC 
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.

http://rhn.redhat.com/errata/RHBA-2013-0364.html
Note You need to log in before you can comment on or make changes to this bug.