[Date Prev][Date Next]
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