Re: Strange TLS behaviour with slapd 2.3.30 on Debian Etch

We experienced the same problem. The culprit turned out to be libldap2 (opposed to libldap-2.3-0), which has GNUTLS support patched in by Debian. To the contrary, ldapsearch is linked against libldap-2.3-0, which uses OpenSSL. More precisely, the problem is get_ca_list() in libraries/libldap/tls.c. If you profile a test program like #include <stdlib.h> #include <dirent.h> #include <stdio.h> #include <sys/param.h> #include <sys/stat.h> #include <gnutls/gnutls.h> gnutls_certificate_credentials_t ca_list; int main(int argc, char *argv[]) { DIR *d; struct dirent *dent; char ca_file[MAXPATHLEN]; struct stat s; char *dir; if (argc != 2) exit(1); dir = argv[1]; d = opendir(dir); if (d == NULL) exit(1); gnutls_global_init(); gnutls_certificate_allocate_credentials(&ca_list); while ((dent = readdir(d)) != NULL) { snprintf(ca_file, sizeof ca_file, "%s/%s", dir, dent->d_name); stat(ca_file, &s); if (!S_ISREG(s.st_mode)) continue; gnutls_certificate_set_x509_trust_file(ca_list, ca_file, GNUTLS_X509_FMT_PEM); } closedir(d); } you see unreasonable amounts of time being spent in memory and string manipulation routines. Not being an TLS/SSL expert, I'm wondering why you need to add all those certificates in the first place. I thought the whole point of all those <subject hash>.<serial> links in /etc/openssl/certs (or whatever) was that a client could find a CA certificate simply by hashing the subject. Another pitfall is that libnss-ldap ignores the tls_cacert{file,dir} directives in libnss-ldap.conf unless "ssl on" is also given. So, if you set the URL to ldaps://..., you end up in OpenLDAP using SSL, but with the parameters given in ldap.conf, not those in libnss-ldap.conf. I've reported this to PADL Soft.