mathz.nu Asterisk Blacklist Hobby webbhotell

This tutorial is part of a series on being your own certificate authority, which was written for Fedora but should also work on CentOS/RHEL or any other Linux distribution.

In the first tutorial of the series, we explored how to act as a certificate authority. We also learnt how to create and sign SSL certificates.

However, an important part of being a CA is certificate revocation. Sometimes we want to revoke access for a particular client, or the certificate may even have been compromised and should no longer be trusted.

A certificate revocation list (CRL) is a list of certificates (or more specifically, a list of serial numbers for certificates) that have been revoked, and therefore, entities presenting those (revoked) certificates should no longer be trusted.

— Wikipedia

Create the CRL

Before we can generate a CRL, we must create a crlnumber file, which openssl requires to keep track of the next CRL number to use:

echo 1000 > /etc/pki/CA/crlnumber

By default, the openssl configuration file (/etc/pki/tls/openssl.cnf) uses V1 CRL lists. Uncomment the crl_extensions = crl_ext line to enable V2 CRL lists. This is probably a good idea unless you have a strong reason to stick with V1 CRL lists (eg, using an Internet browser from the Jurassic period). Now you can generate the CRL.

NB: Note that you can avoid having to specify -keyfile and -cert options by changing the private_key and certificate options in the [ CA_default ] section of your openssl configuration.

cd /etc/pki/CA
openssl ca -keyfile private/ca.key.pem -cert certs/ca.cert.pem \
    -gencrl -out crl/crl.pem

You can view the CRL with this command:

openssl crl -in /etc/pki/CA/crl/crl.pem -text

There are several other CRL options that can be used when generating your CRL list. See the CRL OPTIONS section in the ca manual page (man ca) for more information.

Create an example certificate

Currently, the CRL isn’t particularly interesting as we haven’t created or revoked any certificates yet. Let’s say that Alice is running an Apache web server and has a private folder of really cute kitten pictures. She wants to grant her friend Bob access to this collection.

Alice first needs to create and sign a cryptographic pair for Bob. This is a user certificate, so Alice is using the usr_cert extension when signing the CSR.

openssl genrsa -out /etc/pki/CA/private/bob@kittens.key.pem 4096
chmod 400 /etc/pki/CA/private/bob@kittens.key.pem
openssl req -new \
    -key /etc/pki/CA/private/bob@kittens.key.pem \
    -out /etc/pki/CA/certs/bob@kittens.csr.pem

You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name (full name) []:London
Locality Name (eg, city) [Default City]:London
Organization Name (eg, company) [Default Company Ltd]:Alice CA
Organizational Unit Name (eg, section) []:Client Certificate
Common Name (eg, your name or your server's hostname) []:bob@kittens
Email Address []:bob@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

cd /etc/pki/CA
openssl ca -keyfile private/ca.key.pem -cert certs/ca.cert.pem \
    -extensions usr_cert -notext -md sha1 \
    -in certs/bob@kittens.csr.pem -out certs/bob@kittens.cert.pem
chmod 444 certs/bob@kittens.cert.pem

If we look in the index.txt database, there should now be an entry for Bob’s certificate:

cat /etc/pki/CA/index.txt

V 140825183639Z   1000  unknown /C=GB/ST=London/O=Alice CA/OU=Client Certificate/CN=bob@kittens/emailAddress=bob@example.com

Revoke the example certificate

Turns out Bob wasn’t behaving. He’s been pretending that the pictures are his own and has been selling them for profit. The cheek! Let’s revoke his access immediately.

openssl ca -keyfile private/ca.key.pem -cert certs/ca.cert.pem \
    -revoke certs/bob@kittens.cert.pem

If you take another look at the index.txt database, you’ll see that the V at the start of the line has changed to an R, which means the certificate has been revoked.

cat /etc/pki/CA/index.txt

R 140825183639Z 130825184208Z 1000  unknown /C=GB/ST=London/O=Alice CA/OU=Client Certificate/CN=bob@kittens/emailAddress=bob@example.com

Note that newly created certificates are also placed in the /etc/pki/CA/newcerts directory, with a filename that matches the serial number in index.txt. For example, Bob’s certificate is also located at /etc/pki/CA/newcerts/1000.pem. When revoking certificates you can point openssl at certificates in this directory, which achieves the same thing as revoking certificates in /etc/pki/CA/certs.

Update the CRL

Now that Bob’s certificate has been revoked, we need to re-generate the CRL:

cd /etc/pki/CA
openssl ca -keyfile private/ca.key.pem -cert certs/ca.cert.pem \
    -gencrl -out crl/crl.pem

Let’s take another look at the CRL:

openssl crl -in /etc/pki/CA/crl/crl.pem -text

Certificate Revocation List (CRL):
...
Revoked Certificates:
    Serial Number: 1000
...

Using the CRL

It’s no use just having the CRL sitting in your /etc/pki/CA/crl directory. Applications need to know about your CRL.

In this particular situation, Alice can add the SSLCARevocationPath directive to her httpd.conf. This directive allows Alice to specify a directory containing her CRL files. When Bob tries to access her kitten pictures again, his client certificate has been revoked so Apache will deny him access. Thank goodness!

Similarly, OpenVPN has a crl-verify directive. This can be used to prevent clients with revoked certificates from being able to connect to the VPN.

CRL distribution point

An alternative approach to let applications know about revoked certificates is to use a CRL distribution point. Since the CRL is just a text file, it can easily be distributed by any web server. For example, Alice may keep her CRL at http://example.com/crl.pem.

Add the following to the [ usr_cert ] section of your /etc/pki/tls/openssl.cnf file:

crlDistributionPoints = URI:http://example.com/crl.pem

Now when you sign a CSR using the usr_cert extension the CRL distribution point will be automatically added. You can check if a certificate has a CRL distribution point set by analysing the certificate:

openssl x509 -in www.example.com.cert.pem -noout -text

Certificate:
        ...
        X509v3 CRL Distribution Points:

            Full Name:
              URI:http://example.com/crl.pem
        ...

Applications that support CRL distribution points will periodically download the CRL from the specified URL to check whether any certificates have been revoked.