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!
