Creating Self-Signed Certificates
From Superk
Creating certificates for use with OpenLDAP in an SSL/TLS secure environment seems to cause many difficulty. While I'm still stumbling through the process myself, I thought it best to journal my progress. At the very least, it will help me remember what I've done and perhaps help others.
Contents |
This overview assumes that openssl has been successfully installed. Try doing a 'which openssl' to see if it is indeed installed on your system (usually located in /usr/bin/openssl). Another useful utility to check your system for is the CA.pl or CA.sh scripts that have been built into the openssl package to simplify the creation of certificates (usually in /usr/share/ssl/misc/CA.pl - mine requires root access).
For most testing purposes and for small implementations of the LDAP directory service, a self-signed certificate or local certificate authority (not covered here) is sufficient. If more security is required, additional money will have to be spent to a third-party certificate authority (CA) such as Verisign or similar company. Building a local certificate authority on your network is outside the scope of this article, but can provide for better security and perhaps smoother operation than the use of self-signed certificates. Some programs and applications may even require that the certificates it is using to authenticate security come from a third-party source whether it be local or commercial CA (like Verisign).
However, for simple binds accross our networks using TLS or SSL to connect to OpenLDAP, self-signed certificates should work fine.
Create A Certificate Using OpenSSL Directly
The way that I found to work best to create a self-signed certificate and associated key was to use the openssl program directly. The following command should suffice:
openssl req -new -x509 -nodes -out <cert_file>.pem -keyout <key_file>.pem -days 365
I ran this command from within my OpenLDAP configuration directory (/etc/ldap/) so that it would store the output files there automatically. It's VERY important to get the CN portion of the questionair correct. The CN of the certificate should be the FQDN (Fully Qualified Domain Name) of the server that will be hosting the LDAP directory and this certificate. If you cannot resolve this domain name from another computer (ie, ping <FQDN>), then this will not work correctly. Now, lets break down the switches that are being used (all can be found easily in the man pages of openssl):
- req - Use X.509 Certificate Signing Request (CSR) Management. This is the command that tells openssl to create a self-signed certificate.
- -new - This option generates a new certificate request. It will prompt the user for the relevant field values. The actual fields prompted for and their maximum and minimum sizes are specified in the configuration file and any requested extensions.
- -x509 - This option outputs a self signed certificate instead of a certificate request. This is typically used to generate a test certificate or a self signed root CA. The extensions added to the certificate (if any) are specified in the configuration file. Unless specified using the set_serial option 0 will be used for the serial number.
- -nodes - This option tells openssl not to ecrypt the private key. If the private key is encrypted and password protected, a password would have to be supplied each time the key is accessed.
- -out - This defines the output file for the certificate itself.
- -keyout - This forces the key portion of the certificate to be output to a different file which can then be secured.
- -days - This sets the number of days the certificate will be valid before it expires.
Be sure to change to permissions on the key file to something very restrictive that only the slapd service can read (ie, 0400). For more information on the openssl command used here, http://www.openssl.org/docs/apps/req.html.
Create A Certificate Using the CA.pl or CA.sh Scripts
The CA scripts were created with the intention of making the creation of certificates a much easier process. In many ways this is correct, though I find the command outlined above easier for me. Read the manpage for the CA.pl or CA.sh script for more information on what all it can do, http://www.openssl.org/docs/apps/CA.pl.html. Here is the process for creating a new self-signed certificate using CA.pl:
$/usr/local/misc/CA.pl -newcert
The same questionair that came up for the direct openssl command outlined above comes up for this as well. However the difference is that by default, the CA.pl script creates a single file that contains both the certificate AND the key and it also encrypts the file. There are a few steps that have to be done in order to make the seperate certificate and key files and make them usable without a password:
- Remove the password encryption from the certificate:
$ openssl rsa -in newreq.pem -out <key_file>.pem
This will ask for the password that you supplied when you created the certificate. The resulting files will be the complete certificate (still containing the key) and the new key file you just extracted with the '-out' switch.
- Set the permissions for the key file very restrictive (ie, 0400) and make sure it's owned by the same user that runs the slapd daemon.
- The next step is to remove the key from the original certificate so that the certificate can be made publicly available. Do this by simply opening the newreq.pem file in a text editor (like vi) and deleting out everything including and between the lines '-----BEGIN RSA PRIVATE KEY----' and '-----END RSA PRIVATE KEY'. Save the file and rename it to whatever you like as the certificate. This file should be readable by all (ie, 0644).
Creating a certificate using a certificate generator script
The Debian packages for Courier include a set of scripts that automatically generate SSL certificates to use for IMAPS or POP3S. These scripts can be adapted to make scripts for Apache as well.
The generator script (licensed under the GPL, version 2) looks like:
#! /bin/sh
#
# $Id: mkimapdcert.in,v 1.4 2001/08/26 15:49:50 mrsam Exp $
#
# Copyright 2000 Double Precision, Inc. See COPYING for
# distribution information.
#
# This is a short script to quickly generate a self-signed X.509 key for
# IMAP over SSL. Normally this script would get called by an automatic
# package installation routine.
test -x /usr/bin/openssl || exit 0
prefix="/usr"
if test -f /usr/lib/courier/imapd.pem
then
echo "/usr/lib/courier/imapd.pem already exists."
exit 1
fi
cp /dev/null /usr/lib/courier/imapd.pem
chmod 600 /usr/lib/courier/imapd.pem
chown daemon /usr/lib/courier/imapd.pem
cleanup() {
rm -f /usr/lib/courier/imapd.pem
rm -f /usr/lib/courier/imapd.rand
exit 1
}
cd /usr/lib/courier
dd if=/dev/urandom of=/usr/lib/courier/imapd.rand count=1 2>/dev/null
/usr/bin/openssl req -new -x509 -days 365 -nodes \
-config /etc/courier/imapd.cnf -out /usr/lib/courier/imapd.pem -keyout /usr/lib/courier/imapd.pem || cleanup
/usr/bin/openssl gendh -rand /usr/lib/courier/imapd.rand 512 >>/usr/lib/courier/imapd.pem || cleanup
/usr/bin/openssl x509 -subject -dates -fingerprint -noout -in /usr/lib/courier/imapd.pem || cleanup
rm -f /usr/lib/courier/imapd.rand
The configuration script looks like:
RANDFILE = /usr/lib/courier/imapd.rand [ req ] default_bits = 1024 encrypt_key = yes distinguished_name = req_dn x509_extensions = cert_type prompt = no [ req_dn ] C=US ST=NY L=New York O=Courier Mail Server OU=Automatically-generated IMAP SSL key CN=localhost emailAddress=postmaster@example.com [ cert_type ] nsCertType = server
--Schultmc 13:39, 5 Oct 2005 (CDT)
Modify slapd.conf & ldap.conf
Some modifications are required in both the server and the client for these self-signed certificates to work. On the server side, slapd.conf (usually found in /etc/ldap/slapd.conf) needs a few lines added to recognize the certificate:
TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile <path_to_certificate_pem_file> TLSCertificateKeyFile <path_to_certificate_key_pem_file>
The options in TLSCipherSuite are what tells openssl which forms of authentication to accept as preferred from left to right. Doing an 'openssl ciphers' at the command line will show which ciphers are available to be used. This selection uses ciphers higher than 128-bit by default, then fails over to ciphers at 128-bit, then finally allows all available ciphers for authentication. These items are called cipher suites which each contain a large number of individual ciphers defined by the one value (HIGH, MEDIUM, etc.). See the manpage on ciphers for more info.
On the client side, it is necessary to instruct client programs that it is ok to accept self-signed certificates. This can be done partially by adding a line into the ldap.conf (usually located in /etc/ldap/ldap.conf - don't confuse this with the ldap.conf that's part of the PADL utilities) file:
TLS_REQCERT allow
Note, however, that this may not work for all programs you have. Check the documentation of the individual programs for more information on how to do this. For more information on the OpenLDAP TLS options, http://www.openldap.org/doc/admin21/tls.html.
