*** Bug 713371 has been marked as a duplicate of this bug. ***

Patch submitted upstream: http://www.openldap.org/its/index.cgi?findid=6975

Thank you Rich. I have quickly tested the patch and it seems that the behavior is the same as with OpenSSL now.

Fix included in openldap-2.4.23-16.el6

    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)

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.

(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.

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.

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.

(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.

(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.

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