Bug 726984
| Summary: | matching wildcard hostnames in certificate Subject field does not work | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Phil <beaaegicfqmq6rykaqaakty3lqcg6btv> | ||||||
| Component: | openldap | Assignee: | Jan Vcelak <jvcelak> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | urgent | ||||||||
| Version: | 6.1 | CC: | cww, jplans, jvcelak, omoris, ovasik, tsmetana | ||||||
| Target Milestone: | rc | Keywords: | Regression, ZStream | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| 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.
|
Story Points: | --- | ||||||
| Clone Of: | |||||||||
| : | 733073 (view as bug list) | Environment: | |||||||
| Last Closed: | 2011-12-06 11:49:28 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 733073, 790915 | ||||||||
| Attachments: |
|
||||||||
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. 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.
(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. (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 Resolved in openldap-2.4.23-17.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:
- 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.
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 |
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)