I am trying to implement TLS as per https://help.ubuntu.com/lts/serverguide/openldap-server.html When I try to modify cn=config database with this ldif file:

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/test-ldap-server_cert.pem
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/test-ldap-server_key.pem

I get the following error:

ldapmodify -Y EXTERNAL -H ldapi:/// -f certinfo.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifying entry "cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)

What am I doing wrong?

EDIT: When I try to use simple auth I got the following error:

ldapmodify -x -D cn=admin,dc=example,dc=com -W -f certinfo.ldif
Enter LDAP Password:
ldap_bind: Invalid DN syntax (34)
        additional info: invalid DN
  • Check the permissions on the certificate files. And also remove the password if such is set. – zeridon Jul 10 '15 at 8:37
  • Thanks for the quick answer. The permissions are set to 644 except for .key file which is on 600 How do I check/remove password? I don't remember setting any password for cn=config.. – Amar Prasovic Jul 10 '15 at 8:43
  • 2
    I mean password on the certificate itself (not on cn=config). Check: mnx.io/blog/removing-a-passphrase-from-an-ssl-key – zeridon Jul 10 '15 at 8:47
  • No, that was not the case. The key file was created without password. – Amar Prasovic Jul 10 '15 at 8:50
  • can you try to load the ldiff with simple auth (not -Y EXTERNAL) – zeridon Jul 10 '15 at 8:55

I was following the same guide and had the same issue. It will work if you do the steps to "Tighten up ownership and permissions" listed after the offending ldapmodify command first--namely:

sudo adduser openldap ssl-cert
sudo chgrp ssl-cert /etc/ssl/private
sudo chgrp ssl-cert /etc/ssl/private/ldap01_slapd_key.pem
sudo chmod g+X /etc/ssl/private
sudo chmod g+r /etc/ssl/private/ldap01_slapd_key.pem


sudo systemctl restart slapd.service
  • 1
    This worked for me too! – sonicwave Aug 10 '16 at 12:36
  • 2
    In my case I had to use chgrp openldap. Anyway, it's a permission issue. +1 – xonya Dec 27 '16 at 0:44
  • also private directory must be executable too in order to traverse. sudo chgrp ssl-cert /etc/ssl/private && sudo chmod g+X /etc/ssl/private – Jeff Puckett May 21 '17 at 21:06

Well I don't know if this is a solution or just a workaround, but I managed to get it working.

I first stopped the slapd with:

service slapd stop

Then I started it in debug mode:

slapd -h ldapi:/// -u openldap -g openldap -d 65 -F /etc/ldap/slapd.d/ -d 65

Important is to start it ONLY with ldapi:/// URL. After it started I executed the ldapmodify command and the attributes were imported.

At the end I stopped the debug mode and started the slapd normally.


As a follow-up to A. Gutierrez's answer, the best way to check access for each file is to run sudo -u openldap cat <filename>. I looked at all the files multiple times and they looked to have permissions set correctly. Turned out to be a group problem for openldap. Once I finally figured that out, a simple sudo usermod -a -G ssl-cert openldap solved it for me.


Sometimes the problem is in apparmor profile for slapd service. Be sure that apparmor profile has allowed certificate paths for daemon.

It is quite visually in /etc/apparmor.d/usr.sbin.slapd. By default this profile allows to read certificates in default locations.

Apparmor should prevent unspecified actions for daemon's executable, despite proper unix permissions.

  • If you use letsencrypt, this is the solution. Add the following lines to /etc/apparmor.d/usr.sbin.slapd: /etc/letsencrypt/ r, /etc/letsencrypt/** r, and reload the apparmor profiles. – Bernhard Apr 5 '18 at 12:46

As I reported in this bug on Ubuntu Launchpad, this problem can also be caused by apparmor. Usually this will show in the syslog as an access denial.

The fix is inserting the following line in /etc/apparmor.d/usr.sbin.slapd:

/etc/letsencrypt/** r,

and then refreshing the profile:

# apparmor_parser -vr usr.sbin.slapd
# service apparmor restart

I have this problem also. The problem is the user running slapd didnt has access to certs files. Check out that owner of that files is openldap user.


For me the problem was in wrong order of the records - here is the one that worked:

dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cm_ca_cert.pem
# This never worked for me, no idea why
#add: olcTLSCipherSuite
#olcTLSCipherSuite: TLSv1+RSA:!NULL
replace: olcTLSVerifyClient
olcTLSVerifyClient: never
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/cm_server.pem
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/cm_server.key

Unfortunately this seems to be the "default" error you get for just about anything. @wulfsdad's anwser usually fixes it.

One other thing I always forget is that by default on ubuntu slapd wants the key in openssl format. I regulary but PCKS#8 keys into it and expect it to just work (which to be fair it should). If you tried all the anwsers above also make sure the key has the right format. When googling about the error you usually read about wrong permissions and rub your head why apache works with the very key slapd doesn't like.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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