TLS (Transport Layer Security) and LDAPThe purpose of TLS is to provide security during communication between the client and the LDAP server. It does not secure the information on the LDAP server from inspection by the server administrators. (This requires encryption on the server.) TLS provides security only if both the server and the client support and negotiate it.
NOTE: The differences between TLS and SSL 3.0 (Secure Socket Layer) are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate. There is a mechanism within TLS to back down to SSL 3.0.
If TLS or another security protocol is not used, even though the user passwords are encrypted on the server, they are sent as clear text from the client. Anyone sniffing the network would be able to read this information. BAD! Security is not implemented by hoping that no one tries to break in.
There is a short explanation of TLS configuration at http://www.openldap.org/doc/admin21/tls.html
First a comment on the
openssl command. It is unusual in that it is not just one command but a suite of commands. Each time
openssl is called, it is immediately followed by another command e.g.
genrsa, req which all have various options. Check the man pages for each command.
- Generate a private key for the LDAP server. This is done with
genrsa. The basic command is:
[root@ldap]# openssl genrsa -out ldap.key 2048
The genrsa command generates an RSA (Rivest-Shamir-Adelman 1977) private key. In this case the output file is ldap.key. The 2048 option is the size, in bits, of the private key to generate. This must be the last option specified. The default is 512. 1024 or 2048 would be appropriate choices. Larger keys are more secure but slower.
The private key is just that - private. It should be readable only by the LDAP server process.
- Make a Certificate Signing Request (CSR) to sign a certificate with the key that you have just generated.
[root@ldap]# openssl req -new -key ldap.key -out ldap.csr
You do not need to fill in all the information for the CSR. If you enter '.', the field will be left blank. For the Common Name field, you should use the exact name that clients will use when contacting the server, usually the Fully Qualified Domain Name (FQDN). So if your LDAP server is
ldap.example.com, then put in
ldap.example.comfor the Common Name.
You can either have a registered Certificate Authority like Verisign sign your CSR or you can create your own CA to sign it.
- Create your own self-signed certificate (Skip this step if you already have a registered certificate)
[root@ldap]# openssl genrsa -out ca.key 2048
[root@ldap]# openssl req -new -x509 -days 3650 -key ca.key -out ca.cert
You will have noticed that you have created another private key (
ca.key), this time to be used in creating the Certificate Authority's certificate. The
-des3option encrypts the private key with the triple DES cipher.
ca.certis the certificate for your certifying authority (in this case you). This is later placed on the client machines so that they recognise the CA as a valid authority. Fill in the information here identifying yourself as a CA.
-days 365option. This means your certificate is valid for 365 days from the date of signing. Not before and not after. This means that if your clients have the wrong date set and it is outside the range of the certificate they will not accept the certificate. If you are trying to work out why a particular client won't accept a certificate that all the other clients accept, check the date on the problem client.
- Now you need to sign the CSR using:
[root@ldap]# openssl x509 -req -in ldap.csr -out ldap.cert -CA ca.cert -CAkey ca.key -CAcreateserial -days 365
You have now created a certificate
ldap.certthat is signed by the CA. This is the public certificate for the LDAP server. When a secure connection is requested
ldap.certis sent from the LDAP server to the client. This identifies the server and contains the signature of the CA. The client already has
ca.cert(and maybe others) which tells it which CA's it accepts as valid authorities. The client compares its CA(s) with the signature in
ldap.cert. If they agree then secure communication can begin.
If you wish to examine the contents of a certificate, you can use:
[root@ldap]# openssl x509 -in ldap.cert -text -noout
The LDAP server needs access to a copy of its own certificate and key files, as well as the CA certificate. The key file must only be readable by the server process, so make it mode 0400 and owned by user ldap, group ldap. (I now go for 0640, owner root, group ldap) To make the server aware of these files, edit your slapd.conf file and include:
It makes sense to choose a centralised directory such as
/etc/ssl/openldap to contain the files. However you may choose to place them somewhere else, like
/etc/openssl/keys or another location.
You will need to restart your LDAP server for these changes to take effect.
Similarly, on the client machine you will need to install the CA certificate so that the client will accept certificates that the CA has signed. Let us assume you copy it to
/usr/share/ssl/certs/ca.cert. Then edit
/etc/ldap.conf (See NOTE below) on the client and include :
NOTE: When you install openLDAP it comes with its own ldap.conf (at the top of your openLDAP installation e.g.
/etc/openldap/ldap.conf). Then when you install pam_ldap it too comes with its own ldap.conf (
/etc/ldap.conf). It can become confusing as to which ldap.conf is being read by which application. I created a symbolic link from
Also, some machines have multiple openLDAP installations - so make sure you clean up your installation :-).
An interesting point to note is that the file
ca.cert can contain multiple CA's. They they just need to be concatenated into the file. The order doesn't matter. This can be useful if you are migrating to a new CA. You can push out the new
ca.cert containing both CA's to the clients and then update the certificates on the server at your leisure.
This will now provide transport-level encryption for your LDAP traffic, which will keep the data secure across the network.