In the future I want to use the user accounts stored in the LDAP database on this server also from “outside”. 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:
The content however is old and might be outdated.
I’m asuming all commands are executed as root.
In order to avoid problems with permissions, copy the certificates 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
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 … )
Restart slapd and test it
Fianlley 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.