Re: Windows LDAP Client - SSL Handshake problem

[Tim Murphy <tmurphy@micromuse.com>]

Hi,

Thanks to all who gave me advice on this one - it helped a lot and made 
me think along the right lines.  I have found the problem but not the 
solution yet.

Under windows, the openldap client function, ldap_initialize allows one 
to specify an LDAP URI.  I normally feed it 
"ldaps://myhost.mynet.com:636/"  which should open an ssl connection. On 
various Unices it works but on Windows the SSL handshake fails very 
early on.

After all the advice I got I thought about feeding in the following URI: 
"ldaps://myhost.mynet.com:389/".   The URI should cause OpenLDAP to open 
an encrypted connection but on the port where the non-encrypting 
listener is waiting. (My test LDAP server is set to allow SSL 
connections on 636 and unencrypted connections on 389.)

The connection succeeded and my query worked!  This means that OpenLDAP 
is starting a non-SSL connection even though SSL is requested.

I will investigate further - but perhaps someone else will know the 
answer in advance.

Regards,

Tim

Tim Murphy wrote:

> Hi,
>
> I have compiled the openldap, openssl and cyrus sasl for a windows 
> client.  I am having a problem where the client cannot connect to a 
> server via SSL on port 636.  It's failing in the SSL handshake as the 
> appended slapd debug log shows.
>
> The server is running on Solaris 7 (Sparc).  It can be successfully 
> accessed by the Unix versions of the client and by other tools such as 
> ldapsearch - only the windows client fails.
>
> The windows tool s_client.exe (compiled with openssl) is able to 
> connect to the ldap server quite successfully although it eventually 
> passes the handshake stage and cannot go any further because it 
> obviously doesn't understand the LDAP protocol.  This leads me to 
> think that the problem is somehow intertwined with OpenLDAP.
>
> I shall be having a go at debugging this but I'd appreciate any advice 
> or tips.
>
> Thanks,
>
> Tim
>
>
>
> SLAPD DEBUG TRACE OF A CONNECTION FROM A WINDOWS CLIENT:
>
>
> daemon: activity on 1 descriptors
> daemon: new connection on 9
> daemon: conn=36 fd=9 connection from IP=192.168.34.101:2518 
> (IP=0.0.0.0:0) accepted.
> daemon: added 9r
> daemon: activity on:
> daemon: select: listen=7 active_threads=0 tvp=NULL
> daemon: select: listen=8 active_threads=0 tvp=NULL
> daemon: activity on 1 descriptors
> daemon: activity on: 9r
> daemon: read activity on 9
> connection_get(9)
> connection_get(9): got connid=36
> connection_read(9): checking for input on id=36
> TLS trace: SSL_accept:before/accept initialization
> tls_read: want=11, got=11
>  0000:  30 39 02 01 01 60 34 02  01 03 04                  
> 09...`4....      TLS trace: SSL_accept:error in SSLv2/v3 read client 
> hello A
> TLS: can't accept.
> TLS: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown 
> protocol s23_srvr.c:565
> connection_read(9): TLS accept error error=-1 id=36, closing
> connection_closing: readying conn=36 sd=9 for close
> connection_close: conn=36 sd=9
> daemon: removing 9
> conn=-1 fd=9 closed
> daemon: select: listen=7 active_threads=0 tvp=NULL
> daemon: select: listen=8 active_threads=0 tvp=NULL
> daemon: activity on 1 descriptors
> daemon: select: listen=7 active_threads=0 tvp=NULL
> daemon: select: listen=8 active_threads=0 tvp=NULL