Comment 39 for bug 305264

Revision history for this message
Mathias Gug (mathiaz) wrote :

I was able to reproduce the libldap client bug:

0. Need two versions of openldap : one compiled with gnutls, the other with

1. Create a V1 CA.
2. Create a certificate to be used by slapd and sign it with the V1 CA.
3. Configure a slapd+openssl system with certificates issues above.
4. Try to connect to the slapd+openssl system with a libldap+gnutls client:

mathiaz@t-slapd-gnutls:~$ ldapsearch -b "dc=vmnet" -D "cn=admin,dc=vmnet" -x -w
mypwd -H ldaps://t-slapd-openssl./ -d 1
ldap_new_connection 1 1 0
ldap_connect_to_host: TCP t-slapd-openssl.:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: peer cert untrusted or revoked (0x82)
TLS: can't connect: (unknown error code).
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

I've filed a bug in openldap bug tracker:

Note that a possible workaround is to put *all* of the CA certificates from the chain in the TLS_CACERT file. If one of the intermediate CA certs is a V3 certificate gnutls shouldn't fail and the ldap connection should proceed.

This is actually mentioned in the Admin guide: TLS_CACERT <filename>

  This is equivalent to the server's TLSCACertificateFile option. As noted in the TLS Configuration section, a client typically may need to know about more CAs than a server, but otherwise the same considerations apply.

which points to section TLSCACertificateFile <filename>:

  If the signing CA was not a top-level (root) CA, certificates for the entire sequence of CA's from the signing CA to the top-level CA should be present.