Full_Name: Hallvard B Furuseth Version: HEAD, 2.3, 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080627.diff Submission from: (NULL) (129.240.6.233) Submitted by: hallvard OpenLDAP only uses the default certificates installed with OpenSSL if TLS_CACERT or TLS_CACERTDIR is set. Or presumably TLSCACertificate<File/Dir> in servers, but the libldap/tls.c code for servers seem to require a certificate chain from that directory anyway. To reproduce: $ export LDAPCONF=/dev/null $ ldapwhoami -xZZh ldap.uio.no certificate verify failed $ export LDAPTLS_CACERT="*any* certificate.pem file" $ ldapwhoami -xZZh ldap.uio.no anonymous Or if it still fails, find where OpenSSL wants its default certs: strace ldapwhoami -xZZh ldap.uio.no 2>&1 | grep ssl and temporarily append the root cert which signed our server cert from https://secure.globalsign.net/cacert/CT_Root_CA.pem Then try again. Something like /usr/local/ssl/cert.pem. $ ldapwhoami -xZZh ldap.uio.no anonymous $ unset LDAPTLS_CACERT; ldapwhoami -xZZh ldap.uio.no certificate verify failed The relevant code is in libldap/tls.c:ldap_int_tls_init_ctx(). I enclose a tentative patch which fixes the above problem, but I'm not sure it's the right one for servers and GnuTLS. The GnuTLS branch does not require a server TLSCACertificateFile, but the OpenSSL code does. I don't know if GnuTLS has a default which is used instead, nor if OpenSSL can have that.
h.b.furuseth@usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, 2.3, 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080627.diff > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > OpenLDAP only uses the default certificates installed with OpenSSL if > TLS_CACERT or TLS_CACERTDIR is set. Or presumably > TLSCACertificate<File/Dir> in servers, but the libldap/tls.c code for > servers seem to require a certificate chain from that directory anyway. > Sounds like this works as designed. The docs tell you that either CACERT or CACERTDIR must be explicitly configured. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu writes: > Sounds like this works as designed. The docs tell you that > either CACERT or CACERTDIR must be explicitly configured. Maybe, but in that case the bug is that configuring them to an irrelevant certificate works as a "use the OpenSSL defaults" flag. Which is weird at best. And broke our testing: We thought we checked that certain of our users and clients had updated to use our new cert, but actually we just checked that the OpenSSL installations on the test hosts had the CyberTrust root cert. Which got really confusing when we later tried to get some test clients without the new cert to fail. However if we turn this off (remove SSL_CTX_set_default_verify_paths()), we'll likely break existing installations that (intentionally or not) make use of this feature. (Like some of the clients we supposedly tested:-) Thus it seemed best to always load them. Though OTOH I suppose it's not such a good idea to trust a bunch of certs without being asked to do so. Yet if you can't trust your OpenSSL maintainer... Could add a keyword to turn on (or off) loading of defaults, but I do think it should be independent of whether TLS_CACERT(DIR) have been set. -- Hallvard
changed notes
See also ITS#6248 (multiple CA cert dirs), ITS#8529, ITS#8586
moved from Incoming to Software Enhancements
Waiting for RE25 would have made sense if it had not taken a decade:-( New suggestion: Add keyword TLS_CACERT_DEFAULTS <yes/no/maybe> where the doc explains that "maybe" is the current default and just as silly as it sounds, we recommend yes/no. (Or true/false/on/off like other bools accept) -- Hallvard
Was fixed by ITS#8529 *** This issue has been marked as a duplicate of issue 8529 ***