title: Enabling LDAPS over LDAP in OpenLDAP link: https://onemoretech.wordpress.com/2009/03/23/enabling-ldaps-over-ldap-in-openldap/ author: lembobro description: post_id: 353 created: 2009/03/23 05:25:16 created_gmt: 2009/03/23 05:25:16 comment_status: open post_name: enabling-ldaps-over-ldap-in-openldap status: publish post_type: post

Enabling LDAPS over LDAP in OpenLDAP

I found getting LDAPS enabled in the latest OpenLDAP packages a bit more complicated than it should have been. The main reason for this is that, starting with 8.04 LTS, the Ubuntu developers decided to begin compiling OpenLDAP’s slapd using the gnutls libraries instead of the intergalactic standard, openssl. I will refrain from my usual rants about the hubris of some open source projects and the developers that belong to them for now, but suffice to say the choice of gnutls, a still-experimental and bug infested GPL purist replacement for openssl, is a shocking violation of all that is holy.
IT IS NOT READY… IT IS NOT READY… IT IS NOT READY

Apart from the well-documented security problems with gnutls, its eccentric, Raymondesque (as in Eric Raymond), architecture makes applications compiled using it incompatible with Ubuntu’s default openssl based (and convenient) system-wide /etc/ssl infrastructure. This means that a certificate request created with openssl will not work with the app, nor will any of the root certificates included under /etc/ssl/certs. This is, in my opinion, as serious a bug as could exist for any application.

Given the introduction of the highly complex and poorly documented "cn=config" style configuration in the latest slapd packages for Ubuntu, the entirely undocumented switch from openssl to gnutls strikes me as simply tone deaf. See bug reports attached to the Intrepid Ibex openldap packages.

In the end, I was able to piece together a good enough understanding of what was happening to alleviate the problem on my own systems. What follows is the procedure I used.

1. Create an /etc/ldap/ssl directory owned by the openldap user and group.

2. Retrieve a copy of my CA’s class 3 certificate and put it in this new directory (for this example we’ll call it cacert.pem).

3. Create a server key using the gnutls certtool utility:

certtool --generate-privkey --outfile /etc/ldap/ssl/ldaps_key.pem

4. Create a certificate request using this new private key:

certtool --generate-request --load-privkey ldaps_key.pem --outfile ldaps_req.pem

5. Submit the request to the CA for signing. Copy the resulting signed certificate to /etc/ldap/ssl (in this example we’ll call it ldaps_cert.pem).

6. Do a chmod -R openldap:openldap /etc/ldap/ssl to make sure all perms are set as needed.

7. Edit either “cn=config” on the running slapd server, or stop the server and edit /etc/ldap/slapd.d/cn=config.ldif to add the following lines:

olcTLSCertificateFile: /etc/ldap/ssl/ldaps_cert.pem olcTLSCertificateKeyFile: /etc/ldap/ssl/ldaps_key.pem olcTLSCACertificateFile: /etc/ldap/ssl/cacert.pem

8. Make sure the slapd server is shut down and edit /etc/default/slapd to insert:

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

just under the commented example for this directive.

9. Start up slapd and check the log for errors.

10. Test the proper functioning of LDAPS and TLS using the ldapsearch tool.

Since using ldapsearch to make SSL or TLS is still not a common operational procedure, I’ll repeat the command syntax here — as a public service.

But first, instructions on the prerequisite editing of the /etc/ldap/ldap.conf LDAP client configuration file.

In order to make SSL or TLS connections using ldapsearch, the file /etc/ldap/ldap.conf must be edited to include the following lines:

TLS_CACERT /etc/ldap/ssl/cacert.pem TLS_REQCERT never

where cacert.pem is the name of your CA root certificate.

The reason this is so important is that without the TLS_CACERT environment variable, ldapsearch won’t be able to find your CA’s certificate, and without TLS_REQCERT being set to “never” the client will by default offer to submit a non-existent client certificate to the server — failing the operation.

Once you’ve got the above set up, you can go ahead and issue the following command to test your connection (all on one line):

ldapsearch -x -H 'ldaps://ldap.example.com' -D "cn=admin,cn=config" -w adminpassword -b "dc=example,dc=com" -s base "objectclass=*"

for SSL, and

ldapsearch -x -ZZ -H 'ldap://ldap.example.com' -D "cn=admin,cn=config" -w adminpassword -b "dc=example,dc=com" -s base "objectclass=*"

for TLS (where -ZZ requires the op be successful to insure it actually worked).

Copyright 2004-2019 Phil Lembo