Notes on how to configure various server applications for Transport Layer Security (TLS) support with OpenSSL. These notes assume the service in question has already been compiled with OpenSSL support.
Not all client applications will show diagnostic information. If there are problems initially setting up a service, try using a client that produces more debugging information, as well as increasing any logging possible on the server. To test low level connections, use the s_client option of the openssl utility.
$ openssl s_client -connect mail.example.org:110 -starttls pop3 -showcerts
…
mod_ssl
The mod_ssl module for Apache 1.3 allows the key and certificate files to be specified at build time.
$ make certificate TYPE=existing \
CRT=/etc/ssl/www.example.org.cert \
KEY=/etc/ssl/www.example.org.key
The mod_ssl module does not attempt to verify client certificates by default, so no certificates beyond the one used by the server will need to be setup. If client certificates will be checked, then the SSLCACertificateFile and SSLCACertificatePath options in the httpd.conf preferences file will need to point to certificate areas.
Sendmail
For TLS support in sendmail, use a standard location for certificate data. I usually use the following m4 definitions in my *.mc files for certificate data locations.
define(`CERT_DIR', `/etc/mail/certs')
define(`confSERVER_CERT', `CERT_DIR/host.cert')
define(`confSERVER_KEY', `CERT_DIR/host.key')
define(`confCLIENT_CERT', `CERT_DIR/host.cert')
define(`confCLIENT_KEY', `CERT_DIR/host.key')
define(`confCACERT', `CERT_DIR/cacert.pem')
define(`confCACERT_PATH', `CERT_DIR/CA')
The confCACERT file is a listing of other certificates for verifying other systems with; certificate files can also be hashed into the confCACERT_PATH directory. Sendmail will (by default) attempt to verify connecting clients using the file or hashed directory entries, and will also attempt to verify the server if sendmail is connecting as a client to another server that supports STARTTLS.
If using multiple daemons, try if at all possible to ensure all daemons use the same certificate and key files (or single *.pem file) to simplify daemon setup and debugging. Maintaining multiple files for the same certificate leads to administration problems.
See my sendmail 8.12 configurations for additional examples, or howto relay with TLS in Sendmail.
UW-IMAP
The UW-IMAP 2001 daemons imapd and ipop3d look for certificates under the “OpenSSL certificates” directory, which will depend on how the OpenSSL library and UW-IMAP were compiled. The strings(1) utility may be able to determine the directory from an existing UW-IMAP binary.
# strings /usr/sbin/imapd | grep certs
/usr/share/ssl/certs
UW-IMAP looks for certificate files named after the binary in question: imapd.pem for imapd and ipop3d.pem for ipop3d. The *.pem files must contain both the private key and public certificate data. Administration can be simplified by creating a link from ipop3d.pem to imapd.pem.
Third party certificate authorities will return certificate information. This data will need to be combined with the private RSA keydata into a single *.pem file, as shown in the following example.
# cat host.cert host.key > /usr/share/ssl/certs/imapd.pem
# cd /usr/share/ssl/certs
# ln imapd.pem ipop3d.pem
Like mod_ssl, UW-IMAP does not attempt to verify client certificates, so only the certificate data used by the daemons needs to be setup properly.
More recent versions of UW-IMAP appear to look for imapd-*.pem certificate data files, where the wildcard is replaced with the Internet address of the server being connected to. Presumably one could alias multiple addresses on a server, and return different certificates for different addresses, thus supporting virtual TLS domains.
