CentOS openLDAP cert trust issues

Question

# LDAPTLS_CACERTDIR=/etc/ssl/certs/ ldapwhoami -x -ZZ -H ldaps://ldap.domain.tld
ldap_start_tls: Can't contact LDAP server (-1)
      additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user.

# openssl s_client -connect ldap.domain.tld:636 -CApath /etc/ssl/certs
<... successful tls negotiation stuff ...>
    Compression: 1 (zlib compression)
    Start Time: 1349994779
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

openssl seems to think the certificate is fine, but openldap's libraries (pam_ldap exhibits similar behavior, which is how I got on to this mess) disagree.
What am I doing wrong?

Answer 1

RHEL does not in fact provide anything that can be used as a 'certificate directory' for CA trust purposes. For OpenSSL, a certificate directory - a 'CApath' - is a directory containing individual certificate files (in PEM format or OpenSSL's extended 'trusted certificate' format), with names in a specific format based on a hash of the certificate's subject name. Usually this is achieved by putting files with human-readable names and .pem extensions in a directory and running c_rehash on it (see man c_rehash). For GnuTLS since 3.3.6 (prior to that GnuTLS had no directory support), it's just a directory with PEM files in it; GnuTLS will try and load every file in the directory and succeed on anything PEM-ish (it can't handle OpenSSL's 'trusted certificate' format). I'm not honestly sure if NSS can actually use a directory full of individual certificate files as a trust root somehow, but OpenLDAP's documentation seems to suggest it can (but if the directory also contains an NSS database it'll give that priority). Regardless, RHEL doesn't have anything like a directory full of individual CA certificate files.

Debian and derivatives provide /etc/ssl/certs in this format; /etc/ssl/certs is the canonical trust store location on Debian, and IMO anything that provides it should basically lay it out like Debian's, as Debian's had that directory laid out in more or less the same way since like 1999. RHEL has a /etc/ssl/certs directory, but it is in not in this format - it doesn't contain any individual certificate files at all. You can't use it as a CApath. Honestly, on RHEL (and Fedora, and derivatives) that directory is basically a trap. Don't use it. (See https://bugzilla.redhat.com/show_bug.cgi?id=572725 and https://bugzilla.redhat.com/show_bug.cgi?id=1053882 for some background on why it exists in the first place, and how I'm trying to get it fixed). So I think you're right about what's going on, but wrong about the reason why. OpenLDAP isn't doing anything wrong, and it's not failing because "ca-bundle.trust.crt...is a Mozilla NSS cert/key database" (those are called cert8/9.db and key3/4.db, and the system-wide ones on RHEL live in /etc/pki/nssdb), it's just failing because /etc/ssl/certs is not usable as a 'certificate directory' at all.

RHEL doesn't provide anything usable as a CApath-style trust store anywhere else, either. RHEL's system trust store is provided as a single PEM bundle file (a 'CAfile' in OpenSSL terms), which can be found at /etc/pki/tls/certs/ca-bundle.crt and /etc/pki/tls/cert.pem. It can also be found at /etc/ssl/certs/ca-bundle.crt as /etc/ssl/certs is actually just a symlink to /etc/pki/tls/certs, but that location is not canonical and really shouldn't be used by anything ever. RHEL also provides a bundle in OpenSSL's 'trusted certificate' format as /etc/pki/tls/certs/ca-bundle.trust.crt.

The correct thing to do, as you figured out, is to use the bundle file the system provides. Your answer will work, but for the reasons mentioned above, I would strongly recommend TLS_CACERT=/etc/pki/tls/certs/ca-bundle.crt or TLS_CACERT=/etc/pki/tls/cert.pem over TLS_CACERT=/etc/ssl/certs/ca-bundle.crt.

(There's nothing remotely new in any of this, btw, but confusion on the interwebs is widespread. RH and derivatives have never provided a directory-full-of-certificates, ever. They have provided a bundle file since the year 2000. It was moved from /usr/share/ssl to /etc/pki/tls in 2005. Debian has had both /etc/ssl/certs as a CApath-style directory and /etc/ssl/certs/ca-certificates.crt as a bundle file more or less since the stone age.)

Answer 2

/etc/ssl/certs/ contains /etc/ssl/certs/ca-bundle.trust.crt as part of ca-certificates-2010.63-3.el6_1.5.noarch, which is a Mozilla NSS cert/key database. Inclusion of this file within TLS_CACERTDIR causes all other files to be ignored.

TLS_CACERTDIR
Specifies the path of a directory that contains Certificate Authority certificates in separate individual files. The TLS_CACERT is always used before TLS_CACERTDIR.` This parameter is ignored with GnuTLS.

When using Mozilla NSS, may contain a Mozilla NSS cert/key database. If contains a Mozilla NSS cert/key database and CA cert files, OpenLDAP will use the cert/key database and will ignore the CA cert files.`

However, openldap-2.4.23-26.el6_3.2.i686 doesn't seem to handle this properly.

Short Answer
Use LDAPTLS_CACERT=/etc/ssl/certs/ca-bundle.crt
(config file TLS_CACERT=/etc/ssl/certs/ca-bundle.crt)
This file is also included provided by ca-certificates-2010.63-3.el6_1.5.noarch.

Answer 3

This is a very common problem, don't fret I have an answer for you.

First RHEL Clones have have two ldap.conf files, /etc/ldap.conf or in RHEL6 is is deprecated but you can use /etc/nslcd.conf for authentication now /etc/openldap/ldap.conf is only for queries, so ldapsearch, ldapmodify, ldapremove, it's really your profile so you don't have to have a nasty long string each time you want to run an ldap command.

Now with that out of the way, you have two parameters,

• tls_cacertfile - explicitly define the ca cert and you should be good to go
• tls_cacertdir - drop in the ca cert into the directory but it won't work, because it needs to be hashed ...

use openssl x509 -hash -noout -in $file , ln -s $file $file.0 , then your CA cert will work.

Also note if the config file is in CAPS, you are working in /etc/openldap/ldap.conf, they are very different files.

Hope this clears things up.

Answer 4

Anyone else runs into this; this is what worked for me on centos 6 openldap and sssd:

notes: a. Some "smart guy" decided to make sssd require TLS/SSL; behavior change from centos5; this is great for external systems; but when you have 300+nodes on internal appliance with a unreachable internal network to the machine cluster; this is extremely useless security feature.

b. Furthermore self singed certificates do not seem to work anymore; will continue trying

c. Avoid NSLCD at all costs; was plagued with non-stop issues when i set the legacy flag and used instead of sssd (netgroups; deadlocking syslog, etc..).

To get up and running using sssd;

1. sssd.conf

   [domain/default]
   ldap_id_use_start_tls = True
   id_provider = ldap
   auth_provider = ldap
   chpass_provider = ldap
   cache_credentials = True
   ldap_search_base = dc=local
   enumerate = True
   ldap_uri = ldap://192.168.1.2/
   ldap_tls_cacertdir = /etc/openldap/cacerts
   ldap_tls_reqcert = allow
   ldap_schema = rfc2307bis
   

2. slapd.conf

   TLSCACertificateFile   /etc/openldap/cacerts/ca-bundle.crt
   TLSCertificateFile      /etc/openldap/cacerts/slapd.pem
   TLSCertificateKeyFile   /etc/openldap/cacerts/slapd.pem
   TLSCipherSuite HIGH:MEDIUM:-SSLv2
   

3. ldap.conf

   URI ldap://192.168.1.2/
   BASE dc=local
   
   TLS_CACERTDIR /etc/openldap/cacerts
   

Answer 5

According to the every man page I've seen (but I am not a CentOS user) there is no such thing as LDAPTLS_CACERTDIR. The correct variable to set is TLS_CACERTDIR. You should set it permanently in /etc/openldap/ldap.conf or wherever CentOS keeps the LDAP library configuration file. Also, you may need to configure pam-ldap itself to look for the CA certs. In CentOS this is /etc/pam_ldap.conf, I think, and the variable to set is tls_cacertdir.