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

Re: OpenLDAP-SSL/TLS-IBMSecureWay?

"Kurt D. Zeilenga" wrote:

> Sounds like the client doesn't like the certificate provided
> by the server...
>         Kurt

No, the problem was the change in OpenSSL for the empty fragment
problem.  I have it working under OpenSSL 0.9.6c (back from e) and
if I get it working with 0.9.6g with the "option" enabled I will
call it solved.  Meanwhile the guy who does SecureWays has a new
version for me to test...

I negate the suggestion by noting that the problem occured with
OpenLDAP 2.0.25 which does not check certificates, was also there
on a MacOSX 10.2 OpenLDAP, and we finally got an inkling of what
was happening when OpenSSL did something different between the
good and bad servers: when I opened s-client to 636 the good server
silently ate whatever I typed while the bad server quit after the
first line typed in.  See:


Re: problems with openssl 0.9.6d and up

 From: Lutz Jaenicke 
 Subject: Re: problems with openssl 0.9.6d and up 
 Date: Sun, 08 Sep 2002 03:14:42 -0700 

 On Sat, Sep 07, 2002 at 01:48:35PM +0200, Bart Dumon wrote:
   > i'm trying to post an xml through https, however, it looks like
   > is not going to work with the openssl version i'm using, 0.9.6e
   > when i try to connect with s_client, i get immediately disconnected
   > after the first input line:
   > bartdu?X0040;zeroth:~$ /usr/local/ssl/bin/openssl s_client -connect 
   > partners.networksolutions.com:8010 -quiet
   > depth=1 /C=US/O=RSA Data Security, Inc./OU=Secure Server
Certification Authority
   > verify error:num=19:self signed certificate in certificate chain
   > verify return:0
   > GET / HTTP/1.0
   > bartdu?X0040;zeroth:~$
   > i noticed that it's actually working on other machines, when i
checked the
   > versions of openssl, only the 0.9.6c version seemed to work, so
i've compiled
   > the older and a newer version on the same machine to compare:

 In 0.9.6d a countermeasure against the SSL 3.0/TLS 1.0 CBC
 was added, that turned out to make problems with several peers.
 In 0.9.6e an option was added to return to the old behaviour. It is
 only active, if SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is explicitly set or
 if the application enables all bug workarounds by setting SSL_OP_ALL.
 s_client does not activate the workaround unless it is called with the
 -bugs option. I suppose it should solve your problem.

 Best regards,
 Lutz Jaenicke                            
 BTU Cottbus, Allgemeine Elektrotechnik
 Universitaetsplatz 3-4, D-03044 Cottbus
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                   
 Automated List Manager                          


Thanks to those who answered and apolgies to those who were annoyed.
The fact that the IBM implementation is an integrated SSL/LDAP made
it more difficult than usual to determine which layer was at fault.

> At 07:27 AM 2002-09-19, Charles B Cranston wrote:
> >I'm interested in talking to anybody who has successfully used the
> >OpenLDAP client library to open SSL protected sessions to an IBM
> >SecureWay LDAP server, particularly if it works from a Solaris box.
> >
> >My installation works in non-SSL mode both with SecureWay and several
> >other LDAP servers, and in SSL mode with at least one other LDAP server,
> >but not in SSL mode with SecureWay.  I'd almost suspect something
> >subtly wrong with my local gen, except that the "ldapsearch" from
> >the Apple MacOSX 10.2 version of OpenLDAP (best guess - 2.0.x?)
> >fails with this server in exactly the same way.
> >
> >My setup is OpenSSL 0.9.6e and OpenLDAP 2.1.4 on Solaris.  Server
> >seems to drop the connection right after (or in last stages of) a
> >secure bind.  Interestingly enough, an OpenSSL s_client connect to
> >port 636 of the server also seems to drop the connection as soon as
> >you type "foo bar bletch" at it, while the server that works fine
> >just seems to ignore input till you kill s_client?  Does this sound
> >like it might be a problem with my OpenSSL gen?

Charles B. (Ben) Cranston