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

Re: Strange TLS behaviour with slapd 2.3.30 on Debian Etch

> Quanah Gibson-Mount :
Hopefully all of the Debian specific problems with TLS will go away once OpenLDAP 2.4 is released and integrated into Debian, since it has GnuTLS support. People often run into SSL/TLS issues on Debian because it has a hacked version of OpenLDAP 2.1 libraries linked against GnuTLS, that causes serious problems when the ldap libraries linked against OpenSSL are also loaded.

The mix between openssl and gnutls is my first asumption. I tried some trick in this sense ... I already have problems with /etc/ssl/certs directory, when I use CACertDirs with a lot of certificates in the directory, it was awfully long to get the result, so I switch to CaCertFile instead ... And the problem is only with pam_ldap and not with ldapsearch (or the contrary, I don't remember), and the pam_ldap was linked against gnutls and ldapsearch linked against openssl ...

Do you know when the Openldap 2.4 is planned to be available in Debian and also simply from openldap ?

> Buchan Milne says :
> So, how are you sure this is TLS-specific, and not just lack of (say)
> BDB backend tuning resulting in deferred binds ?

Could you please explain a little bit more your suspicion ? I don't really see what you point out !

> Howard Chu :
> The fact that a reboot is required indicates that any problem is not
> in any user-level code. Maybe your /dev/random has run out of entropy,
> or some other underlying system resource is gone. Maybe strace would
> help here.

For my current problem, I also have doubts about /dev/(u)random and entropy because it was very long to generate a 2048 bits private keys, as the hardware is a Via C7, I switch to /dev/hwrng which is a very good random number generator. And the problem is always here ...

To finish, I put some strace and syslog as requested :


Thanks all for your help

Best regards

Denis Sacchet