Bug 852476 - connection hangs after fallback to second server when certificate hostname verification fails
connection hangs after fallback to second server when certificate hostname ve...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
17
x86_64 Linux
unspecified Severity low
: ---
: ---
Assigned To: Jan Vcelak
Fedora Extras Quality Assurance
:
Depends On: 843056
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-28 12:01 EDT by Jan Vcelak
Modified: 2013-03-03 20:30 EST (History)
5 users (show)

See Also:
Fixed In Version: openldap-2.4.32-3.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 843056
Environment:
Last Closed: 2012-12-20 10:27:56 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Vcelak 2012-08-28 12:01:55 EDT
+++ This bug was initially created as a clone of Bug #843056 +++

Description of problem:

When using OpenLDAP libraries to connect to a ldaps server and you would like to verify server's certificate, it will hang indefinitely if the common name supplied in the LDAP URL does not match the common name on the certificate.


Version-Release number of selected component (if applicable):

openldap-2.4.23-26 - I tested on 64 bit only


How reproducible:


Steps to Reproduce:

1. Your LDAP server must have a certificate signed by CA and issued with common name set to myserver.mydomain.local or whatever name.

2. Try to execute a LDAP query using the following parameters (notice using the IP instead of actual LDAP server hostname):

LDAPTLS_CACERT=CA.pem LDAPTLS_REQCERT=demand ldapsearch -v -x -D "cn=MyName,ou=MyUsers,dc=MyDomain" -y "password_file" -H "ldaps://1.2.3.4" -b "ou=MyUsers,dc=MyDomain" "(&(objectClass=user)(samaccountname=MyUserName))" cn
  
Actual results:

Process is hanging

Expected results:

ldap_initialize( ldaps://hostname:636/??base )
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Additional info:

This was tested against a MS Windows 2008 AD LDAP server.

--- Additional comment from jvcelak@redhat.com on 2012-07-31 12:07:10 CEST ---

I cannot reproduce. Please, can you add '-d-1' option to the ldapsearch command and post the result?

--- Additional comment from florin@flachi.net on 2012-08-02 15:02:01 CEST ---

Hi, it seems like this is my fault that you couldn't replicate, I was actually using 2 servers with -H instead of one as I printed in the bug description.

LDAPTLS_CACERT=CA.pem LDAPTLS_REQCERT=demand ldapsearch -v -x -D "cn=MyName,ou=MyUsers,dc=MyDomain" -y "password_file" -H "ldaps://1.2.3.4 ldaps://1.2.3.5" -b "ou=MyUsers,dc=MyDomain" "(&(objectClass=user)(samaccountname=MyUserName))" cn

ldap_url_parse_ext(ldaps://1.2.3.4)
ldap_url_parse_ext(ldaps://1.2.3.5)
ldap_initialize( ldaps://1.2.3.5:636/??base ldaps://1.2.3.4:636/??base )
ldap_create
ldap_url_parse_ext(ldaps://1.2.3.4:636/??base)
ldap_url_parse_ext(ldaps://1.2.3.5:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 1.2.3.5:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 1.2.3.5:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: loaded CA certificate file /etc/openldap/certs/CAs/MyDomain.pem.
tls_write: want=70, written=70
tls_read: want=5, got=5
tls_read: want=7564, got=2891
tls_read: want=4673, got=4673
TLS: certificate [E=MyAddress@MyDomain.com,CN=MyServer.MyDomain.local,OU=MyOrgzanizationUnit,O=MyOrgzanization,L=MyLocality,ST=MyState,C=MyCountry] is valid
tls_write: want=205, written=205
tls_read: want=5, got=5
tls_read: want=1, got=1
tls_read: want=5, got=5
tls_read: want=48, got=48
TLS certificate verification: subject: E=MyAddress@MyDomain.com,CN=MyServer.MyDomain.local,OU=MyOrgzanizationUnit,O=MyOrgzanization,L=MyLocality,ST=MyState,C=RO, issuer: CN=MyDomainCA,DC=MyDomain,DC=local, cipher: AES-128, security level: high, secret key bits: 128, total key bits: 128, cache hits: 0, cache misses: 0, cache not reusable: 0
TLS: hostname (1.2.3.5) does not match common name in certificate (MyServer.MyDomain.local).
ldap_int_open_connection
ldap_connect_to_host: TCP 1.2.3.4:636
ldap_new_socket: 4
ldap_prepare_socket: 4
ldap_connect_to_host: Trying 1.2.3.4:636
ldap_pvt_connect: fd: 4 tm: -1 async: 0


This is where it gets stuck, when trying to connect to the second server after failing to verify the certificate of the first one.

Could you also edit the original description and remove my private hostname from the 4th line starting at the bottom?

Thanks.

--- Additional comment from florin@flachi.net on 2012-08-02 15:03:40 CEST ---

Also, I made sure that it can successfully connect to both URLs if I specify them using ldaps://hostname1 and ldaps://hostname2.

--- Additional comment from jvcelak@redhat.com on 2012-08-28 13:31:39 CEST ---

Now I can reproduce.

--- Additional comment from jvcelak@redhat.com on 2012-08-28 13:47:46 CEST ---

Created attachment 607485 [details]
reproducer for the bug

$ ./run.sh 
Cleaning up.
Generating certificate.
Starting servers.
Doing the search.
TIMEOUT
Stopping the servers.

--- Additional comment from jvcelak@redhat.com on 2012-08-28 14:38:19 CEST ---

The problem is in Mozilla NSS backend. I tried to recompile with OpenSSL and the bug didn't appear.

--- Additional comment from jvcelak@redhat.com on 2012-08-28 17:57:43 CEST ---

Created attachment 607635 [details]
proposed patch

It seems that the *tls_session is reused when connecting to the second server. Mozilla NSS cannot handle that and hangs inside SSL_ForceHandshake().

I believe the session should not be reused and my patch resolves that.

--- Additional comment from jvcelak@redhat.com on 2012-08-28 17:59:05 CEST ---

Upstream report and patch submission:
http://www.openldap.org/its/index.cgi?findid=7373
Comment 1 Fedora Update System 2012-09-19 05:11:38 EDT
openldap-2.4.32-3.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/openldap-2.4.32-3.fc17
Comment 2 Fedora Update System 2012-09-19 05:13:10 EDT
openldap-2.4.32-3.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/openldap-2.4.32-3.fc18
Comment 3 Fedora Update System 2012-09-20 01:58:08 EDT
Package openldap-2.4.32-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openldap-2.4.32-3.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14390/openldap-2.4.32-3.fc18
then log in and leave karma (feedback).
Comment 4 Fedora Update System 2012-10-07 22:24:22 EDT
openldap-2.4.32-3.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 5 Fedora Update System 2012-12-20 10:27:59 EST
openldap-2.4.32-3.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.