Revoking a signed certificate

Revoking a signed certificate

Sometimes you may need to revoke a certificate. Often this is because the private key has been compromised but it can also be for a variety of other reasons such as the certificate holder leaving the company or a server being decommissioned.

The command below will revoke the mail server certificate we have been using in our examples so far.

Using configuration from /etc/ssl/openssl.cnf 

Enter PEM pass phrase: 

Revoking Certificate 01. 

Data Base Updated 

As you can see the above command takes the certificate file to be revoked as a parameter. Currently there is no way to revoke a certificate using its serial number. This has the serious consequence of requiring the certificate to be revoked be present on the CA. When generating a new certificate for an existing role care must therefore be taken not to overwrite the existing certificate file as revoking the now missing certificate will be impossible.

Generating a Certificate Revocation List (CRL)

Whether any certificates have been revoked or not a Certificate Revocation List should be maintained for the Certificate Authority we have created. Without a CRL users of our certificates will have no way of knowing if we have revoked a certificate or not which, whilst not impacting the security of the transmitted data, may reduce confidence in the certificates issued by our CA.

Thankfully generating a Certificate Revocation List using the openssl application is trivial and can be accomplished with a single command as shown below.

As we mentioned previously an up-to-date CRL is critical to maintaining confidence in the certificates we have issued so even if we have not revoked any certificates we should still maintain and publish a CRL so that users of our CA know that no certificates have been revoked. In a production environment the generation and publishing of CRLs should probably be fully automated using cron or some other suitable automation software.

Examining a Certificate Revocation List (CRL)

The openssl application can be used to display the contents of a CRL which can be useful when debugging or testing a configuration. The command below displays the CRL we generated in the example above.

Certificate Revocation List (CRL): 

        Version 2 (0x1) 

        Signature Algorithm: sha1WithRSAEncryption 

        Issuer: /C=GB/ST=Cambridgeshire/L=Cambridge/O=Hacking Networked Solutions/OU=Certificate Authority/CN=Hacking Networked Solutions Root CA/emailAddress=spamcatcher@hacking.co.uk 

        Last Update: May 28 14:40:09 2009 GMT 

        Next Update: Jun 27 14:40:09 2009 GMT 

        CRL extensions: 

            X509v3 Authority Key Identifier: 

                keyid:22:75:75:B7:70:D9:AA:4C:6D:59:D5:37:F8:82:63:24:F7:20:E3:9F 

                DirName:/C=GB/ST=Cambridgeshire/L=Cambridge/O=Hacking Networked Solutions/OU=Certificate Authority/CN=Hacking Networked Solutions Root CA/emailAddress=spamcatcher@hacking.co.uk 

                serial:AA:B7:2E:92:97:C1:B0:16 

            X509v3 CRL Number: 

                3 

Revoked Certificates: 

    Serial Number: 02 

        Revocation Date: May 28 14:35:20 2009 GMT 

    Signature Algorithm: sha1WithRSAEncryption 

        18:a2:88:90:33:88:6b:13:af:ce:29:f8:df:94:54:50:be:64: 

        12:63:41:10:e8:a0:f2:eb:23:ed:23:70:d1:82:3d:4c:65:9a: 

        68:d8:06:3a:c9:62:c4:be:24:ab:f8:39:ec:34:0d:4e:93:b8: 

        84:6c:6e:00:cb:94:9f:8a:f6:86:de:ea:fd:b2:8b:5d:af:52: 

        9d:3a:48:95:bd:f5:93:a0:6d:45:57:3c:61:16:43:b5:72:ac: 

        d3:8c:46:86:14:7d:be:4a 

As you can see the CRL contains a timestamp indicating when it was last updates as well as a timestamp after which this CRL should be considered invalid. It also contains a CRL number indicating the serial number of the CRL. Below that is a list of all the currently revoked certificates serial numbers along with the timestamp indicating the time and date the certificate was revoked. In our example we have revoked a single certificate.

Publishing the Certificate Revocation List (CRL)

Now that we have generated a (possibly empty) CRL we should publish it in the location we specified when we configured our CA.

Describing the configuration of a web server is beyond the scope of this document however the Web virtual-hosting system using Apache 2 guide describes the configuration of such a system in some detail.

As mentioned when we configured our CA in a previous section the CRL distribution address should not be on an SSL/TLS secured web server which uses a certificate signed by the same CA. If the certificate of the server distributing the CRL was revoked then no future CRLs could be obtained until the certificate was replaced. Also, as the CRL is signed, https adds nothing in terms of security.