[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Strange TLS behaviour with slapd 2.3.30 on Debian Etch



> 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 ...
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.