We're in the business of making you safe. Here is a quick step by step guide to making your authoritative source of authentication and authorization so safe it will bring peace and tranquility to CIOs and CTOs across the globe.
- TLS vs SSL
I am only going to cover TLS here because I believe it is going to be the most useful. In fact, while there are arguments going for SSL, TLS is better. Security wise, the encryption is the same. As a matter of fact, SSL and TLS are the same very thing. The difference here is that SSL implies that the connection be encrypted and then LDAP traffic is carried over the encrypted link. With TLS, a connection is established to the directory server and then, at the client's request, its security can be elevated to a TLS encrypted one with the cunning use of the startTLS extended operation. This means that TLS allows the flexibility to go to and from a secure environment based on mutual agreement by both the server and the client. This means that clients only need to know a single port for both secure and insecure transactions. It greatly simplifies deployment and maintenance, and that too counts as part of improved security.
Dealing with certificates certainly seems like the biggest hurdle to most people that have to go about securing their environment. In the enterprise, this always means that you need your own PKI. For now, I will just show how trivial it is to get started.
- Server Side
- choose a password and store it in a read protected file
echo password1 > key.pwd
echo password2 > keystore.pwd
echo password3 > truststore.pwd
chmod 400 *.pwd
- generate a key pair for the server
#keytool -genkeypair -keyalg RSA -keysize 2048 -keypass password1 -alias server -keystore server.keystore -storepass password2
- export the server public key
We will need the public key later to add it in the trust store on the client side.
#keytool -exportcert -alias server -keystore server.keystore -storepass password2 -file server.cer
- generate a certificate signature request
#keytool -certreq -alias server -keystore server.keystore -storepass password2 -keypass password1 -file server.csr
- submit the csr to your certificate authority (CA), you will get a signed certificate in return and to install it simply import it with the same alias as when you created the key pair
#keytool -importcert -alias server -keystore server.keystore -storepass password2 -file yoursignedservercertificate.cer
- We will now create a trust store. The trust store is usually a good place to store the public keys that you trust and allows you to avoid polluting your keystore. Your key store contains private information. Your trust store contains information that is public. It allows for a clean separation of duties. You can also share your trust store on an NFS share to make it available to all servers while typically the key store would be more protected and specific to each server. In the example below, we create a trust store containing the public key for our CA and intermediate CA:
#keytool -importcert -alias ca -keystore server.truststore -storepass password3 -file ca.cer #keytool -importcert -alias intermediateca -keystore server.truststore -storepass password3 -file intermediateca.cer
- Client Side
Here it is much simpler, we will simply generate a self-signed certificate on the client side. Here's how:
#keytool -genkey -alias client -keystore client.keystore -keyalg RSA -keysize 2048 -storepass password4 -keypass password4
and now let's export the public key so we can later import it in the server trust store: #keytool -exportcert -alias client -keystore client.keystore -storepass password4 -file client.cer
- Mutual trust
Here's how the server knows to trust the client and vice-versa. We need to import the client public key in the server trust store and the server public key in the client trust store.
- Server Side
#keytool -importcert -alias client -keystore server.truststore -storepass password3 -file client.cer
- Client Side
#keytool -importcert -alias server -keystore client.truststore -storepass password5 -file server.cer