This section is a bit brief - it is more of a list of commands and some
simple explanations than a full blown manual type guide.
Unless you know a fair bit about certificates, you will probably want to read the relevent sections of the OpenSSL manuals to supliment this.
Unless you know a fair bit about X509 namespaces / LDAP naming, you probably ought to find your nearest LDAP manual and read up on naming.
In this guide, we will use the same naming conventions used in the certificate installation guide.
Firstly, check you have the correct permissions on your certificate and
key store directories. The <ssl-base-dir>certs/ directory (where
your certificates live) should be world readable, but only writeable by
root (otherwise people can add trojan certificates and have them trusted
as signing certificates). The <ssl-base-dir>private/ directory
(where your private keys live) should only be readable and writable by
root: no-one else should have any access to it.
(If you're uber organised and created a CA-admin's group, the obviously substitute root for CA-admin above.)
Now, backup your key and certificate somewhere very safe.
In order to make your life nice and easy, you may wish to inform OpenSSL to use your new CA stuff by default. You can acheive this by editing openssl.cnf in <ssl-base-dir>. The guides here assume you haven't, if you have you can ignore a lot of the stuff telling openssl where to find keys.
This guide is still incomplete! Most importantly, looking at the CSR's
and editing the fields to go into the certificate has yet to be written
about. As has a guide about letting browsers use their key generation
and CSR generation features.
The guide covers creating a key using OpenSSL, generating a CSR, and generating a certificate without altering any of the fields from the CSR.
Now, send your user their certificate. If they want it for a browser, they'll probably need to convert it to PKCS#12
Note. For this to work, you'll need anything that trusts your certificates to check the latest CRL (Certificate Revokation List), otherwise They won't know you've revoked the certificate.
Note 2. Not all of the files you need for doing CRLs can be specified on the command line, however the config file to use can be (with -config <file>). Therefore, you really need to customise an openssl.cnf file for each CA you run before doing this step, otherwise you'll come unstuck. For an old but good guide on how to do this, see this archived page, or you can also look at this alternate guide.
First up, you need to create a CRL. It is good practice to create a blank CRL straight off, and have your clients check it. That way, when you do come to revoke a certificate, you don't then have the trouble of getting people to notice.
To create a CRL for your CA, you first need to create an index file.
This will initially just be a blank file (created with touch). However,
as you start to revoke certificates, things will go into here.
It's human readable and unsigned, which is why we need to use OpenSSL
to make the signed PEM form of it.
So, once you've got your empty index file (in wherever the openssl.cnf file you've got say's it'll be.... why can't that be a command line option like everything else?), then you can make a CRL from it using:
This will create a CRL for you, valid for the default length of time
(1 month in most OpenSSl versions). In
the case that the CRL is being used only on boxes you control, and where
you are sure you'll update the CRL on following revocation, you'll
probably want to increase the lifetime of the crl. Otherwise, a few
months down the line, your servers will complain the CRL is out of date...
To increase the length of time the CRL is valid for, tack on the option -crldays xxx to the crl command above (where xxx is the number of days to be valid for)
Note - If your CRL expires before you revoke a certificate, just generate a new one, as above. The CRL is simply a signed copy of the internal list of revoked certificates, along with a validity date and placed into a standard format. There's nothing magical about it, you can create a new one whenever you want.
Now, with your initial CRL set up, we revoke a certificate:
This will automagically update your index.txt file with the new details of your revoked certificate. Now you need to generate a new CRL file, with the same command we used above to generate the blank one. With your new CRL created, you need to publish it!
If you want to play around with the validity period of the CRL, or other funky stuff to do with it, then you need to read the "CRL Options" section of the OpenSSL CA manual. If you need to manipulate, view etc a CRL, then take a look at the CRL utility manual.
To ensure that your Apache mod_ssl and/or OpenSSL environment make us of the CRL, take a look at the Installing CRLs page.
To peek at a CRL file, showing things like the validity and what certificates (if any) have been revoked, use: