I've run into essentially the same symptoms as the original poster for this bug: etch slapd (I haven't tried lenny's yet) accepted SSL/TLS connections from etch ldapsearch, but not from hardy or lenny ldapsearch. (I might add that it didn't accept connections from lenny nslcd, package libnss-ldapd, either.) Using openssl s_client or gnutls-cli everything looked all right.
Digging deeper with slapd -d 65535 and ldapsearch -d 65535 I found that in my case the TLS handshake was completing normally: conn=0 fd=15 TLS established tls_ssf=256 ssf=256 but that the client closed the connection immediately afterwards with TLS: peer cert untrusted or revoked (0x42) A clue was provided by the message, earlier in ldapsearch debugging output: TLS: warning: cacertdir not implemented for gnutls This is also documented in the ldap.conf(5) man page, but undeniably constitutes a regression from the earlier OpenSSL-based packages (etch). In my case, switching to single-file TLS_CACERT did solve the problem. I see that the original poster did have tls_cacert (lowercase, but my testing indicates that the keyword is case-insensitive) in ldap.conf. Maybe the file didn't contain the correct CA certificate? Or maybe there is another way of producing essentially the same symptoms? It would be interesting if the original poster could try running ldapsearch with the -d option. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org