Bug 726984 - matching wildcard hostnames in certificate Subject field does not work
Summary: matching wildcard hostnames in certificate Subject field does not work
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openldap
Version: 6.1
Hardware: x86_64
OS: Linux
urgent
high
Target Milestone: rc
: ---
Assignee: Jan Vcelak
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 733073 790915
TreeView+ depends on / blocked
 
Reported: 2011-07-31 19:17 UTC by Phil
Modified: 2018-11-14 09:42 UTC (History)
6 users (show)

Fixed In Version: openldap-2.4.23-17.el6
Doc Type: Bug Fix
Doc Text:
- All programs which use OpenLDAP library to securely connect to LDAP server using SSL/TLS, while the server uses certificate with wildcarded common name (for example CN=*.example.com). - Connection to the server will fail. - The library was fixed to verify wildcard hostnames used in certificates correctly. - The connection will succeed, if the wildcard common name matches the server name.
Clone Of:
: 733073 (view as bug list)
Environment:
Last Closed: 2011-12-06 11:49:28 UTC
Target Upstream Version:


Attachments (Terms of Use)
/etc/nss_ldap.conf (770 bytes, application/octet-stream)
2011-07-31 19:17 UTC, Phil
no flags Details
proposed patch (653 bytes, patch)
2011-08-01 13:33 UTC, Phil
no flags Details | Diff


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 Phil 2011-07-31 19:17:57 UTC
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@redhat.com> 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)

Comment 2 Phil 2011-08-01 08:44:35 UTC
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.

Comment 3 Phil 2011-08-01 13:33:36 UTC
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.

Comment 4 Jan Vcelak 2011-08-08 13:36:22 UTC
(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.

Comment 6 Jan Vcelak 2011-08-08 17:30:33 UTC
(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

Comment 8 Jan Vcelak 2011-08-15 08:24:41 UTC
Resolved in openldap-2.4.23-17.el6

Comment 9 Jan Vcelak 2011-08-15 11:42:04 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:
- All programs which use OpenLDAP library to securely connect to LDAP server using SSL/TLS, while the server uses certificate with wildcarded common name (for example CN=*.example.com).
- Connection to the server will fail.
- The library was fixed to verify wildcard hostnames used in certificates correctly.
- The connection will succeed, if the wildcard common name matches the server name.

Comment 12 errata-xmlrpc 2011-12-06 11:49:28 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.