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

Re: (ITS#6246) SSL fails over a network unless slapd runs with -d 2




On 08/11/2009 04:44 AM, Howard Chu wrote:
> Ed@vanGasteren.net wrote:
>> Full_Name: Ed van Gasteren
>> Version: 2.4.12 and 2.4.15
>> OS: linux (Fedora 10, 11)
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (85.223.76.221)
>>
>>
>> On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server
>> and clients.
>> The configuration is such that things work as expected even with security
>> tightened up to "TLSVerifyClient demand". ldapsearch (either to -H
>> ldaps or with
>> -ZZ), nss and gq with TLS work like a charm.
>>
>> On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15),
>> gq and
>> Thunderbird connecting to the server on lt2. TLS/SSL only works if I
>> run slapd
>> with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS
>> trace:
>> SSL_connect:SSLv3 read server certificate A".
>>
>> Seems as if the normal code path has a flaw which gets
>> corrected/bypassed by the
>> debugging code.
>
> Doesn't sound familiar, I've never had this problem. However, the TLS
> code was refactored in rev 2.4.14, and it's always possible we missed
> something in the churn. How does openssl s_client react under the same
> conditions? If it hangs the same way, then that points to a bug on the

Should have mentioned that. It indeed hangs the same way, in the middle 
of getting over the "Acceptable client certificate CA names".

The last debug info from s_client suggests it is getting less of the 
list then in expects:

read from 0x8c13300 [0x8c19915] (16384 bytes => 10395

The last one coming across correctly is:

/C=US/O=VeriSign, Inc./OU=Class 4 Public Primary Certification Authority 
- G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign 
Trust Network 


The one not coming is:

/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 1 
Policy Validation 
Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com 
 


> server, and the answer is just to upgrade since .12 is rather out of

Hm! I'll see if I can get the 2.4.15 openldap stuff from Fedora 11 
repo's running on lt2 first.

> date now. If s_client works, then we probably have to look at our client
> code.
>