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

Created attachment 516034 [details]
/etc/nss_ldap.conf

Description of problem:
After upgrading from EL6.0 to EL6.1 sudo stopped working. It is configured to retreive it's sudoers over ldap/ssl. The ldap-certificate is a valid Thawte-wildcard (*.domain.tld).

Using unencrypted port 389 (neither SSL nor starttls) sudo works fine.


Version-Release number of selected component (if applicable):
nss-3.12.9-9.el6.x86_64
sudo-1.7.4p5-5.el6.x86_64
openldap-2.4.23-15.el6.x86_64


How reproducible:
Upgrade to RHEL6.1 which comes with openldap 2.4.23, sudo won't work any longer.
Downgrade to openldap 2.4.19-15 and sudo works as expected.


Steps to Reproduce:
1. upgrade openldap from 2.4.19-15 to 2.4.23-15
2. run sudo -l
  
Actual results:
sudo: ldap_sasl_bind_s(): Can't contact LDAP server

Expected results:
sudo: ldap_sasl_bind_s() ok


Additional info:
The attached file is my /etc/nss_ldap.conf. I have a symlink /etc/ldap.conf pointing to /etc/nss_ldap.conf. strace shows that this file is read and used.

The /etc/openldap/ldap.conf simply contains:
--%snip%--
URI ldaps://ldap.foo.example/
TLS_REQCERT never
BASE ou=admins,dc=foo,dc=example
--%snip%--

I presume the issue is related to this (from openldap changelog):

--%snip%--
* Sat Dec 04 2010 Jan Vcelak <jvcelak> 2.4.23-4
- uses Mozilla NSS instead of OpenSSL for TLS/SSL
--%snip%--

When invoking "sudo -l" tcpdump shows that the client FINs the connection after the certificate chains have been retreived.

This is what I tried so far, even though tls_checkpeer is set to "no":
- adding all certificates to /etc/pki/tls/certs, c_hashing them and setting tls_cacertdir to /etc/pki/tls/certs
- adding all certificates to /etc/openldap/cacerts, c_hashing them and setting tls_cacertdir to /etc/openldap/cacerts
- adding all certificates to the nss-database /etc/pki/nssdb and setting tls_cacertdir to "/etc/pki/nssdb"
- setting tls_checkpeer to "yes" (no effect)

--- Additional comment from hash_bugzilla on 2011-08-01 10:44:35 CEST ---

setting "debug" in /etc/ldap.conf gives:

--%snip%--
sudo: ldap_initialize(ld, ldaps://ldap.foo.example/)
sudo: ldap_set_option: debug -> 255
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_set_option: tls_checkpeer -> 0
sudo: ldap_set_option: timelimit -> 30
sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 30)
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.foo.example:636
ldap_new_socket: 5
ldap_prepare_socket: 5
ldap_connect_to_host: Trying aa.bb.cc.dd:636
ldap_pvt_connect: fd: 5 tm: 30 async: 0
ldap_ndelay_on: 5
ldap_int_poll: fd: 5 tm: 301
ldap_is_sock_ready: 5
ldap_ndelay_off: 5
ldap_pvt_connect: 0
TLS: certificate [CN=thawte Primary Root CA,OU="(c) 2006 thawte, Inc. - For authorized use only",OU=Certification Services Division,O="thawte, Inc.",C=US] is not valid - error -8179:Unknown code ___f 13.
TLS certificate verification: subject: CN=*.foo.example,OU=Managed Services,O=XXX,L=XXX,ST=XXX,C=XXX, issuer: CN=Thawte SSL CA,O="Thawte, Inc.",C=US, cipher: AES-256, security level: high, secret key bits: 256, total key bits: 256, cache hits: 0, cache misses: 0, cache not reusable: 0
TLS: hostname (ldap.foo.example) does not match common name in certificate (*.foo.example).
ldap_err2string
sudo: ldap_sasl_bind_s(): Can't contact LDAP server
--%snip%--

1. NSS seems not to accept wildcard certificates.
2. tls_checkpeer is obviously being ignored.

--- Additional comment from hash_bugzilla on 2011-08-01 15:33:36 CEST ---

Created attachment 516137 [details]
proposed patch

I think there might be a confusion between "name" and "domain" in libraries/libldap/tls_m.c. This patch replaces "name" with "domain" and solves my problem.

--- Additional comment from jvcelak on 2011-08-08 15:36:22 CEST ---

(In reply to comment #3)
> Created attachment 516137 [details]
> proposed patch
> 
> I think there might be a confusion between "name" and "domain" in
> libraries/libldap/tls_m.c. This patch replaces "name" with "domain" and solves
> my problem.

You are right. This is correct fix of the issue. Thank you!
I will submit the patch upstream soon.

--- Additional comment from jvcelak on 2011-08-08 19:30:33 CEST ---

(In reply to comment #4)
> I will submit the patch upstream soon.

Well, you already did. ;-) http://www.openldap.org/its/index.cgi?findid=7006

--- Additional comment from jvcelak on 2011-08-15 10:24:41 CEST ---

Resolved in openldap-2.4.23-17.el6