Comment 39 for bug 305264

I was able to reproduce the libldap client bug:

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

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_url_parse_ext(ldaps://t-slapd-openssl./)
ldap_create
ldap_url_parse_ext(ldaps://t-slapd-openssl.:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP t-slapd-openssl.:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 172.19.42.220:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: peer cert untrusted or revoked (0x82)
TLS: can't connect: (unknown error code).
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

I've filed a bug in openldap bug tracker:
http://www.OpenLDAP.org/its/index.cgi?findid=5992

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:

16.2.2.1. 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 16.2.1.1. 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.