[Date Prev][Date Next]
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) (22.214.171.124)
>> 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
>> 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
The one not coming is:
/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 1
> 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