I wrote:
A tls connection between a client and a 2.3.30 slapd hangs while the server is giving the certificate; but this does not happen if the server is run with -d 2 or higher, or if the client is the server itself.
My slapd is the Debian-etch-packaged 2.3.30.
Quanah Gibson-Mount quanah@stanford.edu replied:
Problems with SSL on Debian are well known, and it is due to the fact that they long ago patched OpenLDAP 2.1 to compile against GnuTLS
Thanks for the information. I downloaded and compiled 2.3.32 and I have exactly the same symptom. I used ./configure --with-tls and had to install package libssl-dev for it to work.
Could it be a dependency on a Debian shared library? While investigating whether this is the case with gnutls, I found out that the slapd package does depend on the libgnutls package, but I can't find the library dependence using ldd, and when I try "lsof|grep gnutls", slapd (the Debian slapd) isn't listed there (I can see slapd if I run "lsof|grep libssl). So either the Debian slapd does not actually use gnutls, or I don't know what's going on here (which is very likely).
Here is the dependencies of the compiled slapd:
acheloos:/usr/lib# ldd /usr/local/libexec/slapd linux-gate.so.1 => (0xffffe000) libdb-4.2.so => /usr/lib/libdb-4.2.so (0xb7e7e000) libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7e3f000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7d04000) libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7cf1000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7cdf000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7bae000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7baa000) libz.so.1 => /usr/lib/libz.so.1 (0xb7b96000) /lib/ld-linux.so.2 (0xb7f5d000)