In this issue

One of the most common kinds of access control for secure web servers is Basic Authentication, in which a login and password are required. Access controls can apply to part or all of a web site. The restricted area is called the "authorization realm." Even though Basic Authentication is the most common kind of access control, it is not the most secure. The most secure kind of access control is Client Authentication.

Client Authentication uses client certificates installed in users' web browsers or other client applications (clients) to authenticate users, and only lets clients with the right client certificates into the authorization realm. (In this article, an authorization realm with client authentication will be called a "Client Authentication Realm.")

A client certificate is issued by a Certificate Authority (CA). A CA checks whether a client certificate applicant meets the CA's criteria for trustworthiness before issuing the client certificate. The client certificate is good for access to the Client Authentication Realm until its validity expires. After expiration, the user will be blocked. To renew access, the user's trustworthiness must be reaffirmed by the CA before renewal of the client certificate. This checking when client certificates are issued and renewed helps to ensure that valid client certificates are only in the hands of users trusted to get into the Realm.

However, a client certificate can be compromised before it expires. For example, it can fall into the wrong hands, or the CA may decide that the user it was issued to is not trusted anymore. To reject client certificates which are known to be compromised before expiration, a web server consults a Certificate Revocation List (CRL). A CRL is a list of client certificates that were revoked before they expired. Clients with revoked client certificates will be denied access to a Client Authentication Realm if the revoked client certificates are in the server's CRL.

This article explains how to configure Apache+mod_ssl to keep clients with revoked client certificates out of a Client Authentication Realm. Don't forget to make a backup of your configuration files and keys and certificates before trying these examples. This article assumes that you have:

• Apache+mod_ssl installed on your machine
• A browser that supports client certificates such as Netscape Navigator or Microsoft Internet Explorer
• A revoked client certificate installed in the browser
• The root certificate (rootcert) which signed the client certificate
• The CRL file which includes the revoked client certificate.

The client certificate, rootcert, and CRL file must be issued by a CA. The CA can be a third-party application or service, or OpenSSL (the SSL toolkit on which mod_ssl is based) can be used as a CA. The certificates and CRL must be in the PEM (base64-encoded x509) format required by mod_ssl.

The Client Authentication Realm can be either a secure virtual host or a directory. Make sure these directives are in the secure virtual host or directory container for the Realm in httpd.conf:

SSLVerifyClient require
SSLVerifyDepth 10

After these changes are made and the server is restarted so the changes take effect, clients without client certificates will be kept out of the Client Authentication Realm. Even browsers with client certificates will be denied, unless the rootcert has already been installed on the server. Test this by trying to access the Realm with a browser without a client certificate (or with a client certificate with an uninstalled rootcert).

To let a client with a client certificate into the Client Authentication Realm, the rootcert must be installed. This can be done with the <SSLCACertificateFile> directive (or with SSLCACertificatePath, which will not be covered here). Install the rootcert by adding it to the default SSLCACertificateFile, client-rootcerts.pem. If the rootcert filename is ca.crt, The rootcert can be added with this command:

cat ca.crt >> client-rootcertificates.pem

The rootcert can also be made the SSLCACertificateFile instead of client-rootcerts.pem if none of the other rootcerts in the default SSLCACertificateFile are needed.

After the server is restarted again, browsers with client certificates signed by the installed rootcert will be let into the Client Authentication Realm, even if the client certificates are revoked. Revoked client certificates will not be blocked until the CRL is enabled. Test this by accessing the Realm with a browser that has a client certificate that is revoked and signed by the installed rootcert.

Make a CRL directory such as /ServerRoot/crl/. Copy the CRL file (ca.crl) into the CRL directory, then configure the CRL in httpd.conf with either SSLCARevocationFile or SSLCARevocationPath:

With SSLCARevocationFile, put this directive in the secure virtual host container for the Client Authentication Realm:

SSLCARevocationFile /ServerRoot/crl/ca.crl

SSLCARevocationPath requires two steps. First, put this directive in the secure virtual host container for the Client Authentication Realm:

SSLCARevocationPath /ServerRoot/crl/

Next, make a symlink of the CRL file in the CRL directory, with a filename based on a hash of the CRL file:

ln -s ca.crl `openssl crl -hash -noout -in ca.crl`.r0

Every CRL file in the SSLCARevocationPath must have one of these symlinks.

After the web server is re-started, the CRL will be enabled. Clients with revoked client certificates will not be let into the Client Authentication Realm and will get a browser error message saying that access was denied because the client certificate was revoked. An error message such as this will appear in the /ServerRoot/ssl/error_log:

[Thu Aug 31 15:32:47 2000] [error] mod_ssl: Certificate 
Verification: Error (23): certificate revoked

There are a couple of known problems which may come up because of differences between the CRLs issued by CA software and mod_ssl's requirements. One is that CA software may issue CRLs without the required start -----BEGIN X509 CRL----- and end -----END X509 CRL----- lines. Here is an example of a CRL generated with OpenSSL that works with mod_ssl:

-----BEGIN X509 CRL-----
MIIBmjCCAQMwDQYJKoZIhvcNAQEEBQAwgb0xCzAJBgNVBAYTAlVTMRMwEQYDVQQI
EwpDYWxpZm9ybmlhMRAwDgYDVQQHEwdPYWtsYW5kMRYwFAYDVQQKEw1SZWQgSGF0
LCBJbmMuMSIwIAYDVQQLFBlHbG9iYWwgU2VydmljZXMgJiBTdXBwb3J0MR0wGwYD
VQQDExRSZWQgSGF0IFRlc3QgUm9vdCBDQTEsMCoGCSqGSIb3DQEJARYdc3Ryb25n
aG9sZC1zdXBwb3J0QHJlZGhhdC5jb20XDTAwMTExMzIwNTcyNVoXDTAwMTIxMzIw
NTcyNVowFDASAgEBFw0wMDA4MzEyMTE5MTdaMA0GCSqGSIb3DQEBBAUAA4GBAIge
X5VaOkNOKn8MrbxFiqpOrH/M9Vocu9oDeQ6EMTeA5xIWBGN53BZ/HUJ1NjS32VDG
waM3P6DXud4xKXauVgAXyH6D6xEDBt5GIBTFrWKIDKGOkvRChTUvzObmx9ZVSMMg
5xvAbsaFgJx3RBbznySlqVU4APYE0W2/xL0/8fzM
-----END X509 CRL-----

Another problem is that CRLs issued by third-party CA software may not have all the fields required by mod_ssl. It may be possible to configure the CA software to issue CRLs with all the required fields. Use this OpenSSL command to view the CRL:

openssl crl -text -noout -in filename

Then compare its fields to those in the sample CRL above to see if the same fields are in your CRL:

Certificate Revocation List (CRL):
        Version 1 (0x0)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: /C=US/ST=California/L=Oakland/O=Red Hat, Inc./OU=Global
Services and Support/CN=Red Hat Test Root
CA/Email=stronghold-support@redhat.com
        Last Update: Nov 13 20:57:25 2000 GMT
        Next Update: Dec 13 20:57:25 2000 GMT

Revoked Certificates:

    Serial Number: 01
        Revocation Date: Aug 31 21:19:17 2000 GMT
    Signature Algorithm: md5WithRSAEncryption
        88:1e:5f:95:5a:3a:43:4e:2a:7f:0c:ad:bc:45:8a:aa:4e:ac:
        7f:cc:f5:5a:1c:bb:da:03:79:0e:84:31:37:80:e7:12:16:04:
        63:79:dc:16:7f:1d:42:75:36:34:b7:d9:50:c6:c1:a3:37:3f:
        a0:d7:b9:de:31:29:76:ae:56:00:17:c8:7e:83:eb:11:03:06:
        de:46:20:14:c5:ad:62:88:0c:a1:8e:92:f4:42:85:35:2f:cc:
        e6:e6:c7:d6:55:48:c3:20:e7:1b:c0:6e:c6:85:80:9c:77:44:
        16:f3:9f:24:a5:a9:55:38:00:f6:04:d1:6d:bf:c4:bd:3f:f1:
        fc:cc

If your CA issues CRLs that do not work with mod_ssl and have fields that differ from those in the example shown above, consult your CA administrator or software vendor to see if it can be reconfigured to issue CRLs with the same fields as above, and, if so, how.

CRLs increase the security of Client Authentication Realms by enabling server administrators to block client certificates that have been revoked because they are known to have been compromised. Without CRLs, server administrators would have to wait for the client certificates to expire, or change CA certificates and issue new client certificates to all users who are still trusted to access the Realm. Waiting for the client certificates to expire would risk having untrusted users get into the Realm until expiration, while issuing and installing new client certificates to all users who are still trusted would be a great inconvenience both to server administrators and to users. CRLs allow server administrators to avoid this inconvenience by blocking revoked client certificates without affecting unrevoked client certificates.

The authors would like to thank Shari Miller and Simona Nass for their comments on earlier drafts of this article.