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

(ITS#5657) Broken symlinks in /etc/ssl/certs prevent ssl connection

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) (

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

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
TLS: error:20074002:BIO routines:FILE_CTRL:system lib bss_file.c:358
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.