In the future I want to use user accounts stored in the LDAP on this server from “outside” also. So it’s time to secure outbound connection with SSL before opening the port. Unfortuantly this is a bit tricky. After some trying and googling I got it to work like this:
I’m asuming all commands are executed as root.
1. copy certificates
In order to avoiud problems with rights, copy the cerzificates of the server and the CA as well as the the key of the server to an apropriate place. For example we can use
mkdir /etc/ldap/ssl cp /etc/ssl/certs/ca.pem /etc/ldap/ssl cp /etc/ssl/certs/server.pem /etc/ldap/ssl cp /etc/ssl/private/server.key /etc/ldap/ssl
Then adjust the rights. The files should belong to root, but users of the group opneldap need to read them as well.
chown -R root:openldap /etc/ldap/ssl chmod -R o-rwx /etc/ldap/ssl
2. configure slpad
Create a file
ldap_ssl.ldif with the following content:
dn: cn=config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ldap/ssl/ca.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ldap/ssl/server.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ldap/ssl/server.key
Then load the file into LDAP (using cn=config):
ldapmodify -H ldapi:/// -f ldap_ssl.ldif -D cn=admin,cn=config -w "passwort"
To open Port 636 (ldaps) edit
LAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
(The part with ldaps should be new … )
3. restart slapd and test it
Restart the LDAP-Server using
netstat -tunlp | grep slapd
to check if slapd is listening on port 636. If not something went wrong!
Most problems originate in insufficient rights on certificates and key. For debugging the following commands could be useful – besides a view in the syslog:
slapd -d 1 slapd -d 2 strace slapd
This short tutorial was inspired by http://mindref.blogspot.de/2010/12/debian-openldap-ssl-tls-encryption.html.