RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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:
Embargoed:

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
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1514 0 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> 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.