[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#4144) Strange problem in client libs with SSL connect



Aaron,

thanks for examining this.

Aaron Richton wrote:
> Is this a failing RE23 client?

Yes, RE23 synced from CVS at the time I filed the issue in ITS.

It works with 2.2.27 OpenLDAP libs.

> (I'm not familiar with web2ldap; this could

web2ldap uses python-ldap which is a wrapper module for Python to use
the OpenLDAP client libs. The trace output of python-ldap is also mixed
in the logs and from what I can see looks correct.

> be a lot easier to understand if this was reproduced solely using OpenLDAP
> software e.g. ldapsearch(1)).

As I wrote failing can be reproduced with OpenLDAP's command-line tool
ldapsearch of RE23. It correctly works with ldapsearch of OpenLDAP
2.2.27 and openssl s_client.

If python-ldap is compiled/linked against 2.2.27 libs everything also
works with web2ldap as expected.

> Regardless, the TLS connection (and, as you
> say, the CA configuration) to SunONE appears capable of working at least
> some of the time; otherwise the encrypted

Yes. But the point is "some of the time".

> Now, I doubt that's a fully working application. As you've observed, what
> you're connecting to (i.e. "ldap.e.c" or "directory.e.c") and the CN in
> the cert
> 
>>TLS: hostname (ldap.example.com) does not match common name in
>>certificate (directory.example.com).

Please re-read my message. There were three steps:

I'd expect connecting with the correct hostname in 1. to work but it
didn't. It failed with an error message not related to SSL/TLS at all.

Off course 2. should fail and it fails correctly.

After failing in 2. all attempts to connect with the right hostname are
successful (3.).

After shutting down and restarting the web2ldap process I can reproduce
this behaviour 1. to 3.

>>LDAPError - INSUFFICIENT_ACCESS: {'info': 'Search not permitted for
>>that subtree', 'desc': 'Insufficient access'}
>
> also seems suspicious. Either there's an incompatibilty, you're not

web2ldap trys to read sub schema sub entry, rootDSE etc. But this LDAP
server has strange ACLs which disallow access to some configuration
data. You can simply ignore this since it happens after successfully
connecting through LDAPS.

Ciao, Michael.