Ubuntu 12.04 LDAP SSL self-signed cert not accepted

Question

I'm working with Ubuntu 12.04, using OpenLDAP server. I've followed the instructions on the Ubuntu help pages and can happily connect without security. To test my connection, I'm using ldapsearch the command looks like:

ldapsearch -xv -H ldap://ldap.[my host].local -b dc=[my domain],dc=local -d8 -ZZ

I've also used:

ldapsearch -xv -H ldaps://ldap.[my host].local -b dc=[my domain],dc=local -d8

As far as I can tell, I've setup my certificate correctly, but no matter why I try, I can't seem to get ldapsearch to accept my self-signed certificate.

So far, I've tried:

• Updating my /etc/ldap/ldap.conf file to look like:

 BASE    dc=[my domain],dc=local
 URI     ldaps://ldap.[my host].local
 TLS_CACERT      /etc/ssl/certs/cacert.crt
 TLS_REQCERT allow

• Updating my /etc/ldap.conf file to look like:

base dc=[my domain],dc=local
uri ldapi:///ldap.[my host].local
uri ldaps:///ldap.[my host].local
ldap_version 3
ssl start_tls
ssl on
tls_checkpeer no
TLS_REQCERT allow

• Updating my /etc/default/slapd to include:

  SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"

• Several hours of Googling, most of which resulted in adding the TLS_REQCERT allow

The exact error I'm seeing is:

ldap_initialize( ldap://ldap.[my host].local )
request done: ld 0x20038710 msgid 1
TLS certificate verification: Error, self signed certificate in certificate chain
TLS: can't connect.
ldap_start_tls: Connect error (-11)
    additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

After several hours of this, I was hoping someone else has seen this issue, and/or knows how to fix it. Please do let me know if I should add more information, or if you need further data.

Solution 1

The issue is that the version of GnuTLS that is shipped with Ubuntu 12.04 uses a defective crypto back-end.

GnuTLS was supposed to be switched from using gcrypt as the crypto back-end to nettle but there are licensing issues. Specifically some GPL licenses permit linking with newer or older versions of the GPL and some do not.

You can either rebuild GnuTLS from source configured with nettle or hack gcrypt the way Howard Chu suggested someplace. Instructions on the former are in this bug report.

https://bugs.launchpad.net/bugs/926350

Solution 2

Set the LDAPTLS_REQCERT variable to never to ignore the certificate on the server which could be expired or invalid i.e.:

LDAPTLS_REQCERT=never ldapsearch -D "cn=drupal-test,ou=Services,dc=example,dc=com" -w my_pass -h ldap.example.com -b "ou=People,dc=example,dc=com" -s sub -x -ZZ "(uid=admin)"

or check the server if it has the right certificate.

Solution 3

On the client machine, where you are running ldapsearch, you must have in the ldap.conf

TLS_CACERT /etc/ssl/certs/cacert.crt

I've copied the path from your server configuration where you have stored the CA certificate. Copy the CA certificate from the server to the client at the same location as the path.

See here -- http://www.openldap.org/pub/ksoper/OpenLDAP_TLS.html

Solution 4

I ran into a similar issue - trying to ldapsearch a LDAPS directory server with a self-signed certificate. Here's the actual error you get from ldapsearch with -d8 debug level set:

TLS certificate verification: Error, self signed certificate in certificate chain
TLS: can't connect.
ldap_bind: Can't contact LDAP server (-1)
    additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

I found the server was already setup with "TLS_REQCERT try", so I wanted to not change the actual server's ldap.conf in case it was setup and working for other applications. Found that there is a local config file '.ldaprc' that be used to make ldapsearch (and other utilities) work without the global config. This allowed me to override the TLS_REQCERT setting to become "allow" which solved my ldapsearch issue:

#~/.ldaprc
TLS_REQCERT allow

Here's the output with this in-place and -d8:

TLS certificate verification: Error, self signed certificate in certificate chain
TLS: unable to get peer certificate.
... (actual query works)...

Solution 5

Got this same problem, my fail reason is using LDAP on 12.04 (slapd package is built with GNUTLS) together with my cert which is created used openssl (with CA.pl script)

Solution: Recreate self-signed cert by certtool of GNUTLS, then my LDAP with TLS worked.

View more solutions

Comments

[Dominic Cronin]

+1 for detailed and genuine "So far, I've tried:"

[Sig-IO]

Not really any useful answer, but why not just get a non-self-signed certificate... startssl gives 'm away for free, and they are listed in all OS's and browsers.

[Sig-IO]

Also, if you want to keep on the self-signed path, make sure you make your own CA, and then a certificate for the ldap server, which is signed by this CA. So not self-signed, but signed by your own (self-signed) CA certificate.

[MaddHacker]

@Sig-IO - We did try to setup our own CA, still the same issue. We really wanted to find a local way to do this, since it's all internal systems, and we could have a lot of them. I'll have a look at startssl to see if that might be a viable option.

[Peter]

why did this horrible answer help me the most... simply seeing here you can set a config option in this way made me test and find that it does work (not to disable ssl to fix ssl, which is unhelpful, but to set my CA cert with LDAPTLS_CACERT=...). And then I decided to strace to see why it can't find that in conf. I found that apparently there aren't just 2 copies of the same file, but 3... there's /etc/ldap.conf, /etc/ldap/ldap.conf, and discovered now there is /etc/openldap/ldap.conf.

[Peter]

I just discovered one more... on arch based, there's also /etc/nss_ldap.conf

[James]

I'm running openldap in docker. It's an alpine container apparently. All I want to do is prove my TLS is working. This is exactly what I needed, I needed to create a .ldaprc file in ~/ within the container, use TLS_CACERT and then the path of the file (mine is /ssl/mydomain.com-ca.crt) and then I could run the ldapsearch with TLS_REQCERT set to demand.

[Ben Aveling]

@Peter This doesn't disable tls. It does bypass checking the certificate the server returns, so you can't be sure who you're talking to, but at least you're not sending your password in plaintext.