GNOME Bugzilla – Bug 268826
LDAPS not functional for CA certs imported in Evolution
Last modified: 2021-05-19 11:03:58 UTC
LDAP via SSL is not functional (can't connect) if LDAP server uses certificate signed by non-standard CA. Even if CA certificate is imported into Evolution's CA certificates, it's not used by LDAP backend. Possible workaround is to launch Evolution using this command: LDAPTLS_CACERT=<path to CA cert PEM file> evolution Tested on e-d-s version 1.0.2 (note that you don't have this version in Bugzilla). For details, follow discussion in this thread: http://lists.ximian.com/archives/public/evolution/2004-October/040073.html
the problem, I think, is that the LDAP code doesn't use the same SSL code that the rest of evo sues (it uses OpenSSL as part of OpenLDAP rather than the Mozilla NSS stuff everything else, like the mailer, does)
What if I run my own OpenLDAP server with a self-signed certificate and no CA? Is it possible to get this to work? I tried setting LDAPTLS_CACERT to the PEM file for my OpenLDAP directory but that didn't work. FWIW, Thunderbird is able to access my OpenLDAP directory without a CA verifying the self-signed certificate.
Actually, my current workaround is this line added to /etc/ldap/ldap.conf: TLS_CACERT=<path to directory with certificate>/cacert.pem
Still present in e-d-s 1.3.6. I changed my workaround to export LDAPTLS_CERT=<path to directory with certificate>/cacert.pem Please move this bug to new target milestone, I'm not sure I can do that without asking someone.
retargetting from 1.1 to 1.5 to get rid of that busted milestones (as discussed with harish on irc) jan: yeah, thanks.
This bug still exists in 2.8.1 and the work around does not seem to work anymore either.
doesn't work either on debian testing or unstable (evo-2.6)
With CentOS 5.3, evolution 2.12.13 communicates fine via ldaps with an LDAP server using CA-signed certificates. Configuration: server openldap.i386 2.3.43-3.el5 client evolution-data-server.i386 1.12.3-10.el5_3.3 evolution.i386 2.12.3-8.el5_2.3 However, as described in comment (3), on the client running evolution, /etc/ldap/ldap.conf must contain TLS_CACERT=<path to directory with certificate>/cacert.pem and user must have a ~/.ldaprc with TLS_CERT <path to directory with certificate>/client.pem TLS_KEY <path to directory with certificate>/client-key.pem If there are no attempts made to fix this bug, in the meantime, why not document this behaviour in the evolution administration guide??? This will save any administrator installing this solution a lot of trouble.
from the previous comment >and user must have a ~/.ldaprc with >TLS_CERT <path to directory with certificate>/client.pem >TLS_KEY <path to directory with certificate>/client-key.pem This is only true if the server contains a TLSVerifyClient demand in its slapd.conf and this is what is used.
Correction to Jan/Dietrich's workaround: Add to /etc/ldap/ldap.conf: TLS_CACERT /path/to/certificate.crt (NO equals sign, crt certificates also work, I assume pem certificates do too) Also, I didn't need the TLS_CERT and TLS_KEY directives. Also, five years, and four years without a developer response? Really?
Hi Matt, >Add to /etc/ldap/ldap.conf: >TLS_CACERT /path/to/certificate.crt >(NO equals sign, crt certificates also work, I assume pem certificates do too) Correct. > Also, I didn't need the TLS_CERT and TLS_KEY directives. Did you verify, that the server issued a STARTTLS command and verified the client certificate? As I write above >This is only true if the server contains a >TLSVerifyClient demand >in its slapd.conf and this is what is used. Please comment on the fact, that this behavior is not documented.
I can confirm that this is still a bug in Evolution 2.28, as ships with Ubuntu Lucid. In fact, it is worse, as I can't seem to get the workaround working. Either setting TLS_CACERT /path/to/cacert.pem in ~/.ldaprc or the environment variable LDAPTLS_CACERT does not work for evolution. However, when I run ldapsearch, e.g. ldapsearch -x-H 'ldaps://ldap.example.com:2336/' -b ou=addressbook,dc=david,dc=example,dc=com -D 'uid=david,ou=users,dc=example,dc=com' -W It works when TLS_CACERT is set in the ~/.ldaprc or via the environment variable, but it does not work when TLS_CACERT is not set. It's not clear to me whether the ldap library routines used in eds check for these environment variables or not - I am beginning to suspect not, as I could find any information on the openldap.org website about this.
This is still an issue with evolution 3.4. Can someone update the versions accordingly?
Note that even when the certificate is present in /etc/ssl/certs and /etc/ssl/certs/ca-certificates.pem it won't validate. Looking at a network trace, it seems completely broken, the only SSL packet I get is “SSL Continuation data” without any ClientHello.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/ Thank you for your understanding and your help.