Managing SSL Certificates #1

SSL certificates can be confusing. The combination of unreadable file contents, fussy configuration requirements and critical expiry dates strew traps in the path of the beginner.

This how-to will help you avoid SSL's most common pitfalls.


Common difficulties

Some of the common difficulties that newcomers to SSL certification may experience:

     1.  SSL certificate updates that break your SSL site when you first reload Apache after updating the old certificate      file.

     2.  Confusing certificate and key file-names that obfuscate which certificate and key files are valid for which year,      or domain, or both!

     3.  Confusing key and certificate file locations.

     4.  Web servers that won't start when the server is rebooted unless a password is first entered at the console.

First, I'll show you a couple of good-practice tips that will make your SSL sites less error-prone as your sites mature and grow. We'll then move onto how to verify certificates regardless of whether they are self-signed or not. And we'll finish up with how to remove the password from password-protected SSL certificates.

Certificates and keys — file locations

SSL's default file locations vary among Linux distributions so let's first map the terrain.

If you installed the SSL modules using your slice distribution's package manager then the distribution's default web server expects certificate and key files to be placed in particular directories.

Here are the standard locations:

Red Hat and CentOS

     /etc/httpd/conf/ssl.key/
     /etc/httpd/conf/ssl.crt/

Ubuntu and Debian

     /etc/apache2/ssl/
     -or-
     /etc/ssl/
     (varies according to the Ubuntu/Debian version)

Administrators of multiple-domain web servers often place the key and cert files in their own choice of directories, usually grouped by website domain.

If you did that, hopefully you remember where they are. If not, you may be able to produce a shortlist of likely locations by running the following search commands.

To find certificates and keys:

sudo find / | egrep -i '\.crt|\.key|\.pem' | egrep -vi 'doc'

To find ssl-related directories:

sudo find / | egrep -i 'ssl' | egrep -vi '/usr/|log'

.pem, .crt, .key

Don't be confused by references to .pem, .crt and .key files. They are all PEM format (ASCII files encoded in Base64 format), and the only difference between them is that .pem files combine the key and certificate in one file, while .crt and .key file files separate the certificate from the key.

From the web server software's point of view, it doesn't matter as long as the web server's web site configuration file contains key and certificate stanzas that point to the correct file.

However, separate .key and .crt certificates create more opportunities for mis-matched keys and certificates so we will focus on those in this article.

Minimizing errors

Having mapped the terrain, let's look at how we can minimise SSL errors.

Most SSL errors occur at set-up and when certificates are renewed. Set-up issues are easily avoided if you follow our various SSL how-tos, so we will focus here on renewal issues.

A common cause of errors is that you already have a certificate file in place from the previous year. If you renewed in a timely manner, that certificate is still valid but its file has to be removed or over-written when you upload the updated certificate file. So, at the very least, copy the original certificate file to a safe location before over-writing it.

Organizing with names and aliases

However, there is a safer, quicker, rollback-enabling method that also makes for easier management of the certificate collection that can build up when hosting multiple SSL domains on one server.

This two-part method is to use descriptive names for key files and certificate files instead of their default filenames. And to use symbolic links to manage which of them the web-server considers 'current'.

For example, "www.domain.com.crt" is an obvious certificate filename on the day you first create it, but it is less obvious three years later when you are are working amid the certificate files for six SSL-capable sites, three of which are having updated certificates applied, and now you are trying to rollback from an SSL error that seems to be caused by some key mis-match.

If you use filenames like "www.domain.com.crt.2009" and "www.domain.com.key.2009" you can visually date any key or certificate file and easily identify the key-certificate pair.

At first glance, this practice forces you to edit the web server's domain-specific configuration files every time you update SSL certificates, which would be a hassle.

However, this is where the second part — symbolic links — comes to the rescue. Here's how you do it.

After you create the original "www.example.com.crt.2009" and "www.example.com.key.2009" files, create symbolic links to those two files like this, assuming you are working on a Red Hat-based filesystem (CentOS, Fedora):

ln -s /etc/httpd/conf/ssl.crt/www.example.com.crt.2009 /etc/httpd/conf/ssl.crt/www.example.com.crt

This creates a "fake" certificate file:    /etc/httpd/conf/ssl.crt/www.example.com.crt.

cd ../ssl.key/

ln -s /etc/httpd/conf/ssl.key/www.example.com.key.2009 /etc/httpd/conf/ssl.key/www.example.com.key

Similarly, this creates a "fake" key file:    /etc/httpd/conf/ssl.key/www.example.com.key.

Obviously, you should change the path locations to suit your key/cert file placement.

Using this tactic, your web server's SSL site-configurations can point to the symbolic links instead of the files ending in ".2009"

When you add a renewed SSL certificate, you simply give it a filename like:

     /etc/httpd/conf/ssl.crt/www.example.com.crt.2010

Then remove the existing symbolic links and create new ones pointing to the ".2010" file

rm /etc/httpd/conf/ssl.crt/www.example.com.crt
...
ln -s /etc/httpd/conf/ssl.crt/www.example.com.crt.2010 /etc/httpd/conf/ssl.crt/www.example.com.crt

Easy! Do the same thing with a key-file if you update the key.

If the web server reports an SSL error when you restart or reload it, you can simply roll-back by deleting the symlink and then create a new symlink that points back to your known-working SSL certificate.

Remember, each time you make any changes related to your SSL certificates, you'll need to restart the web server.

Summary

With this technique, you will be able to manipulate certificate and key files without having to delete, move or rename the files as your collection of certificates and keys grows.

In Managing SSL Certificates #2, you'll learn how to check for certificate and key problems before making them live on your site.

Want to comment?


(not made public)

(optional)

(use plain text or Markdown syntax)