I first encountered this when I got informed by Luma that I could not connect to a server. I then reproduced this on the command line: $ ldapsearch -H ldaps://ldap.domain.tld ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) $ ldapsearch -d 15 -H ldaps://ldap.domain.tld ... ldap_connect_timeout: fd: 3 tm: -1 async: 0 TLS: could not load client CA list (file:`',dir:`/etc/ssl/certs/'). TLS: error:0906D06C:PEM routines:PEM_read_bio:no start line pem_lib.c:647 ... previous line repeated 13 times ... TLS: error:02001002:system library:fopen:No such file or directory bss_file.c:356 TLS: error:20074002:BIO routines:FILE_CTRL:system lib bss_file.c:358 ldap_perror ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Sadly it does not say what file can't be opened. The "no start line" errors seem to be non-fatal. The fopen error in bss_file.c from dev-libs/openssl on the other hand seems to cause the connection to fail. Root of the cause seemed to be several broken symlinks in /etc/ssl/certs. Steps to solve the issue by removing those links: # find /etc/ssl/certs -type l ! -xtype f ! -xtype d -ok rm -f {} \; Steps to reproduce the issue, provided you have an SSL-Enabled LDAP server: # ln -s bar.pem /etc/ssl/certs/foo.pem $ ldapsearch -d 15 -H ldaps://ldap.domain.tld I hads tried running update-ca-certificates to solve the issue, but it left these stale symlinks in place: SPI_CA_2006-cacert.pem -> /usr/share/ca-certificates/spi-inc.org/SPI_CA_2006-cacert.crt Verisign_Class_1_Public_Primary_OCSP_Responder.pem -> /usr/share/ca-certificates/mozilla/Verisign_Class_1_Public_Primary_OCSP_Responder.crt Verisign_Class_2_Public_Primary_OCSP_Responder.pem -> /usr/share/ca-certificates/mozilla/Verisign_Class_2_Public_Primary_OCSP_Responder.crt Verisign_Class_3_Public_Primary_OCSP_Responder.pem -> /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_OCSP_Responder.crt Verisign_Secure_Server_OCSP_Responder.pem -> /usr/share/ca-certificates/mozilla/Verisign_Secure_Server_OCSP_Responder.crt spi-ca.pem -> /usr/share/ca-certificates/spi-inc.org/spi-ca.crt The cause of the issue seems to be more likely in openldap than in openssl itself, because other SSL services seem to work well enough and I could even successfully establish a connection using $ openssl s_client -CApath /etc/ssl/certs -connect ldap.domain.tld:636 Suggested ways of addressing this issue: 1. Have update-ca-certificates not suppress error output from c_rehash, as the latter faithfully complains about broken links. You could also improve update-ca-certificates to issue a big (red) warning if the certs directory contains broken links, and do so even if it did not change anything and thus would not run c_rehash. This would help people realize there is something amiss. You could also interactively ask the user whether to delete some or all of these symlinks, if you have a mind to, or simply print the above command for it. 2. Have openldap treat such errors as non-fatal, the way s_client seems to do it. This is probably an issue for upstream, I guess.
Created attachment 162959 [details, diff] Show errors from c_rehash Patch update-ca-certificates from app-misc/ca-certificates-20080514-r1 to show errors from c_rehash.
Cross references to upstream bug reports I filed for this. Debian about ca-certificates including patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495224 OpenLDAP about behaviour for broken symlinks: http://www.openldap.org/its/index.cgi/Incoming?id=5657 or http://www.openldap.org/its/index.cgi?selectid=5657 if message got moved.
Note from the Debian report: Debian has openldap linked against gnutls, not openssl, and therefore seems not to be affected by this. The gnutls support seems to be new in openldap 2.4, which is still package.masked at the moment. The gnutls USE flag seems to be already in place in those ebuilds. I also have a better link for the openldap issue report, deprecating the two links given above: http://www.openldap.org/its/index.cgi?findid=5657
ca-certificates patched and set to warn anybody that has broken symlinks - they shouldn't exist on any new installs, only on old ones. OpenLDAP really shouldn't be responsible for having a broken cert setup. I'm pretty sure that it's the inside of OpenSSL that fails like this, I saw a similar failure from Apache years ago.
*** Bug 235267 has been marked as a duplicate of this bug. ***
*** Bug 242230 has been marked as a duplicate of this bug. ***
