Bug 859858

Summary:	libldap does not load PEM certificate if certdb is used as TLS_CACERTDIR
Product:	Red Hat Enterprise Linux 6	Reporter:	Jan Vcelak <jvcelak>
Component:	openldap	Assignee:	Jan Vcelak <jvcelak>
Status:	CLOSED ERRATA	QA Contact:	David Spurek <dspurek>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.5	CC:	dave, dspurek, ebenes, jsynacek, jvcelak, rhatlapa, rmeggins, tsmetana
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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	Environment:
Last Closed:	2013-02-21 09:46:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	857455
Bug Blocks:

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