> 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 :
http://www.ouba.org/strace.slapd.no.probleme.tls.200712070838
http://www.ouba.org/strace.slapd.probleme.tls.200712070809
http://www.ouba.org/syslog.slapd.tls.problem.200712070804
Thanks all for your help
Best regards
Denis Sacchet