Setting up your SSL certificates on OpenLDAP by using a Mozilla NSS database

I’ve recently spent some time setting up TLS/SSL encryption (SSSD won’t send a password in clear text when an user will try to authenticate against your LDAP server) on an OpenLDAP istance and as you may know the only way for doing that on a RHEL / CentOS environment is dealing with a Mozilla NSS database (which is, in fact, a SQLite database). I’ve been reading all the man pages of the relevant tools available to manipulate Mozilla NSS databases and I thought I would have shared the whole procedure and commands I used to achieve my goal. Even if you aren’t running an RPM based system you can opt to use a Mozilla NSS database to store your certificates as your preferred setup.

On the LDAP (SLAPD) server

Re-create *.db files

Setup a CA Certificate

where ca.pem should be your CA’s certificate file.

Remove the password from the Database

Creates the .p12 file and imports it on the Database

where domain.org.key and domain.org.crt are the names of the certificates you previously created at your CA’s website.

List all the certificates on the database and make sure all the informations are correct

Configure /etc/openldap/slapd.conf and make sure the TLSCACertificatePath points to your Mozilla NSS database

Additional commands

Modify the trust flags if necessary

Delete a certificate from the database

On the clients (nslcd uses ldap.conf while sssd uses /etc/sssd/sssd.conf)

On /etc/openldap/ldap.conf

On /etc/sssd/sssd.conf

How to test the whole setup

Troubleshooting

If anything goes wrong you can run SLAPD with the following args for its debug mode:

Possible errors: 

If you happen to see an error similar to this one: “TLS error -8049:Unrecognized Object Identifier.“, try running ldapsearch with its debug mode this way:

Make also sure that the FQDN you are trying to connect to is listed on the trusted FQDN’s list of your domain.org.crt.

Update: as SSSD’s developer Stephen Gallagher correctly pointed out on the comments using ldap_tls_reqcert = allow isn’t a best practice since it may take in Man in the Midle Attacks, adjusting the how to to match his suggestions.

Share on Google+1Tweet about this on TwitterShare on Facebook9Share on LinkedIn2Digg thisShare on Reddit0Share on StumbleUpon0Email this to someone