Bug 713525 - ldapsearch fails if no CA certificate is available
Summary: ldapsearch fails if no CA certificate is available
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openldap
Version: 6.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jan Vcelak
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
: 713371 (view as bug list)
Depends On:
Blocks: 716854
TreeView+ depends on / blocked
 
Reported: 2011-06-15 17:08 UTC by Najmuddin Chirammal
Modified: 2018-11-14 12:06 UTC (History)
12 users (show)

Fixed In Version: openldap-2.4.23-16.el6
Doc Type: Bug Fix
Doc Text:
- openldap clients configured with TLS_REQCERT=never and TLS_CACERTDIR set to an empty directory - TLS connection to remote server fails as TLS can not be initialized on client side - TLS_CACERTDIR errors are ignored when TLS_REQCERT is set to never - OpenLDAP client tools now have the same behavior as before, when OpenSSL library for SSL/TLS was used (currently we use Mozilla NSS library)
Clone Of:
: 716854 (view as bug list)
Environment:
Last Closed: 2011-12-06 12:12:47 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1514 normal SHIPPED_LIVE openldap bug fix and enhancement update 2011-12-06 00:51:20 UTC

Description Najmuddin Chirammal 2011-06-15 17:08:12 UTC
Description of problem:

With latest openldap (RHEL6.1) ldapsearch or similar tools fails to contact ldap server if there are no certificates in /etc/openldap/cacerts directory. With the option "LDAPTLS_REQCERT never" the same command works well in the previous version(s) of openldap (openldap-2.4.19-15.el6_0.2 or older)

Version-Release number of selected component:openldap-2.4.23-15.el6.x86_64

How reproducible:

Always.

Steps to Reproduce:
1. Upgrade openldap to openldap-2.4.23-15.el6
2. make sure /etc/openldap/cacerts directory is empty
3. ldapsearch as shown below.
 
# LDAPTLS_REQCERT=never ldapsearch -x -H ldaps://hostname:port -s base -b ""
  
Actual results:
ldapsearch fails with the following error.

ldap_connect_to_host: Trying 10.65.210.164:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: did not find any valid CA certificates in /etc/openldap/cacerts
TLS: could not initialize moznss using security dir /etc/openldap/cacerts prefix  - error -8174.
TLS: could perform TLS system initialization.
TLS: error: could not initialize moznss security context - error -5939:No more entries in the directory
TLS: can't create ssl handle.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)


Expected results:

No errors, ldapsearch returns requested data.

Additional info: Discussed with "Richard Megginson" on irc, as rich suggested I tried removing the option TLS_CACERTDIR from /etc/openldap/ldap.conf file and fixed the issue.

Comment 3 Rich Megginson 2011-06-16 17:04:39 UTC
*** Bug 713371 has been marked as a duplicate of this bug. ***

Comment 4 Rich Megginson 2011-06-21 00:39:01 UTC
Patch submitted upstream: http://www.openldap.org/its/index.cgi?findid=6975

Comment 5 Jan Vcelak 2011-06-21 13:00:48 UTC
Thank you Rich. I have quickly tested the patch and it seems that the behavior is the same as with OpenSSL now.

Comment 10 Jan Vcelak 2011-07-18 15:56:00 UTC
Fix included in openldap-2.4.23-16.el6

Comment 12 Jan Vcelak 2011-08-15 10:30:09 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
- openldap clients configured with TLS_REQCERT=never and TLS_CACERTDIR set to an empty directory
- TLS connection to remote server fails as TLS can not be initialized on client side
- TLS_CACERTDIR errors are ignored when TLS_REQCERT is set to never
- OpenLDAP client tools now have the same behavior as before, when OpenSSL library for SSL/TLS was used (currently we use Mozilla NSS library)

Comment 13 Ondrej Moriš 2011-09-28 11:51:35 UTC
What if TLS_CACERT is set incorrectly and TLS_REQCERT is set to "never"? From my point of view, ldapsearch should return results and exit successfully. The reasoning behing that is given by man page:

never  The client will not request or check any server  certificate.

But it actually fails (redhat1.pem does not exist):

# LDAP_REQCERT=never LDAPTLS_CACERT=/etc/openldap/cacerts/redhat1.pem ldapsearch -x -H ldaps://ldap.bos.redhat.com -b dc=redhat,dc=com 'uid=omoris' -d1
ldap_url_parse_ext(ldaps://ldap.bos.redhat.com)
ldap_create
ldap_url_parse_ext(ldaps://ldap.bos.redhat.com:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.bos.redhat.com:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 10.16.255.3:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: could not read certificate file /etc/openldap/cacerts/redhat1.pem - error -5950:File not found.
TLS: /etc/openldap/cacerts/redhat1.pem is not a valid CA certificate file - error -5950:File not found.
TLS: could perform TLS system initialization.
TLS: error: could not initialize moznss security context - error -5950:File not found
TLS: can't create ssl handle.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
TLS: could not shutdown NSS - error -8053:Unknown code ___f 139.

Comment 14 Jan Vcelak 2011-09-28 12:10:42 UTC
(In reply to comment #13)
> What if TLS_CACERT is set incorrectly and TLS_REQCERT is set to "never"? From
> my point of view, ldapsearch should return results and exit successfully. The
> reasoning behing that is given by man page:
> 
> never  The client will not request or check any server  certificate.
>

I asked upstream developers about this situation (see bug #644119 for a reference). They claim, that if something is configured wrong, you might not expect that it will work at all.

Comment 15 Ondrej Moriš 2011-09-28 13:16:14 UTC
I think this is different, consider the following:

* /etc/openldap/ldap.conf contains TLS_CACERT=x used for some LDAP server X

1. When I query LDAP server X, cacert x is used and everything is fine.
   
   ldapsearch -x -H ldaps://X ... (pass)

2. When I query LDAP server Y, cacert x is incorrectly used

   ldapsearch -x -H ldaps://Y ... (fail)

3. To prevent using wrong cacert x for Y, I will try to avoid it:

   LDAPTLS_REQCERT=never ldapsearch -x -H ldaps://Y ... (fail)

   but it won't work, AFAIK there is no workaround as this does not work as well:

   LDAPTLS_CACERT="" LDAPTLS_REQCERT=never ldapsearch -x -H ldaps://Y ... (fail)

I guess that this is not nothing special, ie. to have configured /etc/openldap/ldap.conf for some LDAP servers (X, ...) and to query other LDAP servers (Y, ...) directly.

Comment 16 René Hartman 2011-09-29 04:55:20 UTC
I concur with Ondrej. If the developers refuse to correct this based on the quoted claim, they shouldn't have fixed this bug either, as pointing to an empty TLS_CACERTDIR can be considered a configuration erro as well, but then that's negated by 'TLS_REQCERT allow' or 'TLS_REQCERT never'. That is, if they aim to be consistent.

If the configuration specifies to never request certificates, the software should never request (or check for, as they're not going to be requested anyway) certificates. That would be the only consistent behavior, imho. And as Ondrej points out, it's inconsistent with the man page as well.

According to the man page, even 'TLS_RQCERT allow' should work, the difference between 'never' and 'allow' being that 'allow' WILL check, and IF a valid certificate is present, it will be used. Can't test that, but maybe Ondrej can?

Functionality as documented in the man page makes sense, the behavior observed by Ondrej does not. It takes away the documented flexibility.

Comment 17 Ondrej Moriš 2011-09-30 10:30:32 UTC
(In reply to comment #16)
> I concur with Ondrej. If the developers refuse to correct this based on the
> quoted claim, they shouldn't have fixed this bug either, as pointing to an
> empty TLS_CACERTDIR can be considered a configuration erro as well, but then
> that's negated by 'TLS_REQCERT allow' or 'TLS_REQCERT never'. That is, if they
> aim to be consistent.

I have discussed this with Jan (please correct me if I am wrong) and it turned out that the problem here is that openldap initiates TLS at first and then decides whether to verify or not to verify server's certificate validity. Thus in my example, this initialization failed since TLS_CACERT pointed to non-existing certificate. 

> If the configuration specifies to never request certificates, the software
> should never request (or check for, as they're not going to be requested
> anyway) certificates. That would be the only consistent behavior, imho. And as
> Ondrej points out, it's inconsistent with the man page as well.

That's right, it should be said in man page that even with TLS_REQCERT=never, TLS is initiated (and I am going to open a separate BugZilla for that).
 
> According to the man page, even 'TLS_RQCERT allow' should work, the difference
> between 'never' and 'allow' being that 'allow' WILL check, and IF a valid
> certificate is present, it will be used. Can't test that, but maybe Ondrej can?

Fortunately, this works fine.

> Functionality as documented in the man page makes sense, the behavior observed
> by Ondrej does not. It takes away the documented flexibility.

I have to add an additional note - when LDAPTLS_CACERT points to some valid CA certificate such that server's certificate _is not_ signed by this CA, then LDAPTLS_REQCERT=never works fine (server's certificate is not verified).  

All in all, the only remaining problematic situation is when TLS_CACERT points to non-existing or broken certificate. It would be nice to have some way how to "disable" such TLS_CACERT. Anyway, issued described in this bugzilla report seems to be resolved and I am fine the proposed fix. So lets postpone aforementioned additional issues to a separated bugzilla.

Comment 18 Jan Vcelak 2011-09-30 13:26:24 UTC
(In reply to comment #17)
> I have discussed this with Jan (please correct me if I am wrong) and it turned
> out that the problem here is that openldap initiates TLS at first and then
> decides whether to verify or not to verify server's certificate validity. Thus
> in my example, this initialization failed since TLS_CACERT pointed to
> non-existing certificate. 

You are right. Just to be precise: the TLS connection has to be initialized first. Any errors are ignored when REQCERT is set to try/allow. If the connection can not be initialized due to invalid settings (file with certificates can not be opened), we will not get to any verification.

> All in all, the only remaining problematic situation is when TLS_CACERT points
> to non-existing or broken certificate. It would be nice to have some way how to
> "disable" such TLS_CACERT.

We can also create a RFE bug for this.

The problem is, that OpenLDAP source code can be linked against OpenSSL, Mozilla NSS, GNU TLS. There is an abstraction layer over these. The error codes exchanged between the crypto backend and the abstraction layer are very general. Changing the behavior would require changes in each crypto backend specific code and even in the abstraction layer. And we have to provide consistent behavior for each backend, therefore we will need to patch and test everything. Otherwise there is no change that upstrem would include these changes.

Comment 20 errata-xmlrpc 2011-12-06 12:12:47 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-2011-1514.html


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