Full_Name: Martin von Gagern Version: 2.3.43 OS: Gentoo Linux URL: https://bugs.gentoo.org/show_bug.cgi?id=234816 Submission from: (NULL) (84.188.31.84)
On systems with broken symlinks in the default certificate directory of openssl, I found it impossible to establish an ldaps connection with openldap.
I originally reported this issue as https://bugs.gentoo.org/show_bug.cgi?id=234816
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
Ideally openldap should trat these errors as non-fatal, the way s_client does, so that such a broken symlink won't prevent all connections.
If that path towards solution proves infeasible (as the openssl function SSL_add_dir_cert_subjects_to_stack seems to behave this way and adding all files manually might be a pain), at least there should be some error message telling the user that the problem lies in the local SSL certificates setup, not really in the network connection or remote configuration.
By the way, I'm using openssl version 0.9.8h.