I simply cannot get this (TLS connection to openldap) to work and would appreciate some assistance.

I have a working openldap server on ubuntu 10.04 LTS, it is configured to use cn=config and most of the info I can find for TLS seems to use the older slapd.conf file :-(

I've been largely following the instructions here https://help.ubuntu.com/10.04/serverguide/C/openldap-server.html plus stuff I've read here and elsewhere - which of course could be part of the problem as I don't totally understand all of this yet!

I have created an ssl.ldif file as follows;


add: olcTLSCipherSuite
olcTLSCipherSuite: TLSV1+RSA:!NULL
add: olcTLSCRLCheck
olcTLSCRLCheck: none
add: olcTLSVerifyClient
olcTLSVerifyClient: never
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/ldap_cacert.pem
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/my.domain.com_slapd_cert.pem
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/my.domain.com_slapd_key.pem

and I import it using the following command line

ldapmodify -x -D cn=admin,dc=mydomain,dc=com -W -f ssl.ldif

I have edited /etc/default/slapd so that it has the following services line;

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

And everytime I'm making a change, I'm restarting slapd with /etc/init.d/slapd restart

The following command line to test out the non TLS connection works fine;

ldapsearch -d 9 -D cn=admin,dc=mydomain,dc=com -w mypassword \
-b dc=mydomain,dc=com -H "ldap://mydomain.com" "cn=roger*"

But when I switch to ldaps using this command line;

ldapsearch -d 9 -D cn=admin,dc=mydomain,dc=com -w mypassword \
-b dc=mydomain,dc=com -H "ldaps://mydomain.com" "cn=roger*"

This is what I get;

ldap_new_connection 1 1 0
ldap_connect_to_host: TCP mydomain.com:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: can't connect: A TLS packet with unexpected length was received..
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Now if I check netstat -al I can see;

tcp        0      0 *:www                   *:*                     LISTEN
tcp        0      0 *:ssh                   *:*                     LISTEN
tcp        0      0 *:https                 *:*                     LISTEN
tcp        0      0 *:ldaps                 *:*                     LISTEN
tcp        0      0 *:ldap                  *:*                     LISTEN

I'm not sure if this is significant as well ... I suspect it is;

openssl s_client -connect mydomain.com:636 -showcerts
916:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

I think I've made all my certificates etc OK and here are the results of some checks;

If I do this;

certtool -e --infile /etc/ssl/certs/ldap_cacert.pem

I get Chain verification output: Verified.

certtool -e --infile /etc/ssl/certs/mydomain.com_slapd_cert.pem

Gives "certtool: the last certificate is not self signed" but it otherwise seems OK?

Where have I gone wrong? Surely getting openldap to run securely on ubuntu should be easy and not require a degree in rocket science!

Any ideas?


Roger's link has since rotted, here is the same on the Internet Archive's WayBack Machine, as of the last date archived before he changed his site: https://web.archive.org/web/20150530064010/http://rogermoffatt.com/2011/08/24/ubuntu-openldap-with-ssltls/

I've also taken the liberty to append his content below as well:

The Starting Point

I’m going to assume that you have a working openldap installation (not secured) using cn=config (the LDAP database) for configuration rather than the old style slapd.conf variation. If you are making changes by editing slapd.conf, then the rest of this article is not for you!


Create some self-signed certificates to get started. If you’ve already created some certificates for a web server using openssl, the first thing that will catch you out is that they won’t work with ldap. You need certificates in a different format and to generate them we need a new tool that you won’t have yet.

sudo -i
apt-get update
apt-get install gnutls-bin
certtool --generate-privkey --outfile /etc/ssl/private/ldap-ca-key.pem
certtool --generate-self-signed --load-privkey /etc/ssl/private/ldap-ca-key.pem --outfile /etc/ssl/certs/ldap-ca-cert.pem

Fix your permissions – the resulting files need to be readable by the openldap group.

To do this, add the openldap user to the ssl-cert group and then ensure the certs and key are owned by the ssl-cert group. Remember that the directory /etc/ssl/private has strict permissions on it so you need to get this right.

adduser openldap ssl-cert
chgrp /etc/ssl/private/ldap-ca-key.pem


Create a suitable ssl.ldif file for importing into the configuration database. It’s worth saying at this point that the ones I’ve seen online have all had syntax errors in that have prevented them from working – and they fail silently which makes you think they have worked! Note especially that the hyphens are syntactically important.

dn: cn=config
changetype: modify
add: olcTLSCipherSuite
olcTLSCipherSuite: NORMAL
add: olcTLSCRLCheck
olcTLSCRLCheck: none
add: olcTLSVerifyClient
olcTLSVerifyClient: never
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap-ca-cert.pem
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap-ca-key.pem

WARNING: Don’t be clever and change the TLSCipherSuite to something clever like HIGH:MEDIUM:-SSLv2 – this is an openssl directive and you will now find that you can’t restart slapd as it will fail on startup :-( To diagnose this, try starting slapd with the following command;

slapd -d 16383

If you do this, you will probably see the following;

TLS: could not set cipher list HIGH:MEDIUM:+SSLv2.
main: TLS init def ctx failed: -1

You can fix this by editing /etc/ldap/slapd.d/cn=config.ldif directly if you are careful.


Import the ssl.ldif file and be aware of what you should see when it works, as opposed to what you will see when it doesn’t. Also be aware that if you are running this multiple times, you need to change the add to replace in the ssl.ldif file.

ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif -v

The -v gives you a verbose output. Make sure that you see the new entries being printed out, if it just says something like;

modifying entry "cn=config"
modify complete

Then this DOES NOT mean it has worked. It quite likely means it hasn’t processed the file because of errors and no changes will actually have been made. You need to see it list the entries it has modified. For example, this is a working version (using replace, not add)

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
replace olcTLSCipherSuite:
replace olcTLSCRLCheck:
replace olcTLSVerifyClient:
replace olcTLSCertificateFile:
replace olcTLSCertificateKeyFile:
modifying entry "cn=config"
modify complete


Ensure that slapd listens for ldaps:// connections We’re off to edit a file again (is anyone else thinking that using cn=config is causing more hassles than it solves?), this time we need to edit /etc/default/slapd and change the SLAPD_SERVICES line so that it has the ldaps:/// entry as shown here;

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


Fix the untrusted certificate problem. You’d think we’d be done by now, but it turns out there is one configuration in another file that is really important. If you try to connect now, using a command line that binds to the ldap server such as this;

ldapsearch -d 9 -D “cn=admin,dc=mydomain,dc=com” -w adminpassword -b “dc=mydomain,dc=com” -H “ldaps://mydomain.com” “objectClass=*”

You will probably get;

TLS: peer cert untrusted or revoked (0x42)
TLS: can't connect: (unknown error code).
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

To resolve this, edit the file /etc/ldap/ldap.conf (note that this is not the slapd.conf file – it can be a bit confusing) and add the single line below to what is probably a completely commented out file; TLS_REQCERT never

Now it should work!

  • 2
    Note that I take no copyright for his content, nor can I vouch for how effective it is at solving the problem. I simply didn't like that the critical part of the answer had nearly vaporized. – Ricky C Jul 25 '16 at 17:31
  • This is the only place where I found a correct set of steps that works on Debian 9 after struggling for hours. One tiny addition: be sure the private key file ldap-ca-key.pem has group read permissions, after setting its group ownership to ssl-cert. That was the only, and very minor, hiccup in this process. Without that the ldapmodify command fails with ldap_modify: Other (e.g. implementation specific) error (80). – mklein9 Jan 25 '20 at 5:54
  • 1
    I wish this was more complete - running --generate-self-signed gives a load of options and I don't know which ones are needed. This thing needs to be entirely automated as well. – James May 3 '20 at 12:51
  • @James I know it's a bit late, but I've added the rest of the missing details as I worked through this in another answer. – fei0x Apr 12 at 15:44

It seems the syntax of my ssl.ldif file is incorrect. After following a different guide online, I changed it to this (and also regenerated self-signed certificates).

dn: cn=config
changetype: modify
add: olcTLSCipherSuite
olcTLSCipherSuite: NORMAL
add: olcTLSCRLCheck
olcTLSCRLCheck: none
add: olcTLSVerifyClient
olcTLSVerifyClient: never
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/new-ca-cert.pem
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/new-ca-key.pem

This hasn't fully solved it yet, but at least now I can use;

openssl s_client -connect mydomain.com:636 -showcerts

And actually get a result. I'll update this answer as I find out more.


I've written up my solution at http://rogermoffatt.com/2011/08/24/ubuntu-openldap-with-ssltls/ which might help someone else. Such a palaver!

  • I can't leave a comment on your site, so here it is: You may want to add how to force TLS, because it still accepts unencrypted connections. When I find out how, I'll let you know :) – Halfgaar Dec 20 '12 at 15:21
  • use following to force TLS: ` dn: cn=config changetype: modify add: olcSecurity olcSecurity: tls=1 ` or check this for more: serverfault.com/questions/459718/… – HVNSweeting Apr 17 '13 at 9:03
  • I LOVE YOU! For two days i have been trying to fix this problem not getting it to work. The ubuntu documentation did not help at all. But this did. Thanks alot! (not possible to post comment on your blog) – larsemil Jun 6 '14 at 9:02

I worked through some issues getting Roger and Ricky's answers to work, and thought I'd put some of that here.

Updates to Step One

When creating the self signed cert, I only had to enter data for these fields. The rest i was able to skip past without specifying:

  • Common name: my.domain.com
  • The certificate will expire in (days): 999999
  • Does the certificate belong to an authority? (y/N): N
  • Enter the IP address of the subject of the certificate:

The commands for setting the permissions on the cert files can be as follows:

chgrp ssl-cert /etc/ssl/private/ldap-ca-key.pem
chgrp ssl-cert /etc/ssl/certs/ldap-ca-cert.pem
chmod g+r /etc/ssl/private/ldap-ca-key.pem
chmod g+r /etc/ssl/certs/ldap-ca-cert.pem

Checking them:

ls -al /etc/ssl/certs/ldap-ca-cert.pem
ls -al /etc/ssl/private/ldap-ca-key.pem

should show:

-rw-r--r-- 1 root ssl-cert 1484 Apr  9 17:31 /etc/ssl/certs/ldap-ca-cert.pem
-rw-r----- 1 root ssl-cert 8289 Apr  9 16:29 /etc/ssl/private/ldap-ca-key.pem

Also be sure that the size of the file isn't 0. If it is you didn't make the cert properly, you'll need to do it again.

Updates to Step Three

If you're unsure what the current settings in the ldap are to know if you should use "add" or "replace" then you can run this line to check:

sudo slapcat -b cn=config | grep olcTLS

If you don't see the entries, then you'll still need to use "add"

New Checks

Another issue I had, was that my machine hostname wasn't properly matching the common name I entered into the certificate. In order to set the hostname properly on an Ubuntu 16.04 machine I ran:

hostnamectl set-hostname qa-data.theaccesshub.com

This was the cause of an '80' error I got when applying the ldif file:

ldap_modify: Other (e.g., implementation specific) error (80)

Also don't forget to open port 636 on your machine. Otherwise you will get a connection timeout when trying to access that port.


All this got me SSL/TLS working without issue. When connecting with LDAP Admin, it does prompt you about the self-signed cert, but you can okay it and all is good.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.