OpenLDAP with TLS and LetsEncrypt on Ubuntu 16.04

Using TLS (SSL) certificiates with OpenLDAP

Every time we added this, an error cropped up:

A project I’m working on requires a Kerberos and LDAP infrastructure. Most technology projects are easy to do badly, and more difficult to do well – and documented.

We use LetsEncrypt to issue a certificate to each server, and OpenLDAP can take the certificate and use it to encrypt and authenticate connections from other LDAP servers.

One of the problems I encountered was when setting up replication between servers. We use SaltStack to build and maintain our server estate, so deployment and configuration needs to be automated. This normally means spending a week automating a process which you’ll only do twice – once when you install it, and once again when you’re rebuilding the server and have forgotten everything you’ve done.

To secure OpenSSL, add this LDIF file to your directory:

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/letsencrypt/live/ldap1.example.com/fullchain.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/letsencrypt/live/ldap1.example.com/cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/letsencrypt/live/ldap1.example.com/privkey.pem

Every time we did this, a vague error popped up:

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

Restarting slapd, the LDAP daemon, with full debugging showed nothing, neither did running the daemon through strace.

Several days of painful troubleshooting followed. We eventually found the issue – the LDAP daemon wasn’t able to access the TLS certificates! AppArmor was blocking access to the files under /etc/letsencrypt, and so we did two simple things.

First, we used setfacl to give the openldap user ‘rx’ permissions on /etc/letsencrypt/live and /etc/letsencrypt/archive:

$ sudo setfacl -m user:openldap:r-x /etc/letsencrypt/live
$ sudo setfacl -m user:openldap:r-x /etc/letsencrypt/archive

This lets the LDAP daemon read and following the symbolic links in the live directory to the actual files.

Next, we needed to tell AppArmor to let the LDAP daemon, slapd, access the files themselves. It’s as easy as creating a file called /etc/apparmor.d/local/usr.sbin.slapd with the following:

/etc/letsencrypt/live/{{ grains.id }} r,
/etc/letsencrypt/archive/{{ grains.id }} r,
/etc/letsencrypt/archive/{{ grains.id }}/** r,

The trailing comma on the last line isn’t a mistake – if you don’t include it, AppArmor won’t install the rule. I won’t admit how long it took us to realise this!

5 thoughts on “OpenLDAP with TLS and LetsEncrypt on Ubuntu 16.04”

    1. If I’ve understood your question correctly, here’s what I have in the Salt state file:

      ldap-access-to-machine-live-dir:
        acl.present:
          - name: /etc/letsencrypt/live
          - acl_type: user
          - acl_name: openldap
          - perms: rx
      
      ldap-access-to-machine-archive-dir:
        acl.present:
          - name: /etc/letsencrypt/archive
          - acl_type: user
          - acl_name: openldap
          - perms: rx
    2. I think you meant “sudo setfacl -m user:openldap:r-x /etc/letsencrypt/live” and “sudo setfacl -m user:openldap:r-x /etc/letsencrypt/archive”

  1. YEEEEEEEEEEEESSSS! FINALLY! THANK YOU!

    I can’t say how many hours I have read blogs and Stack articles which only gave half the story, or where someone hacked the permissions in a way most don’t want.

    Your instructions about setfacl and the three lines for apparmor was what finally made it work.

    I had already tried all kinds of combinations of permissions for the directories and files, even manually copying the certificates elsewhere, and that didn’t work either.

    Don’t forget to restart apparmor and slapd after adding the access exceptions.

    service apparmor restart
    service slapd restart

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.