Certificate Management and Generation with OpenSSL

Back to the guides index

Guides In This Section

Setting up your OpenSSL CA

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.)

In <ssl-base-dir>private/ create your CA keypair (key_size is in bits, if you don't know otherwise then probably 1024 is the right figure for you):
openssl genrsa -aes256 -out CA.key <key_size>
Set this file to root read only (so you can't then accidently delete it), and everyone else no access. Next, decide on you CA certificate naming issues. As a guide, for the Magdalen College JCR CA, we opted for:
C=UK, L=Oxford, O=Magdalen College JCR, OU=Certificate Authority, CN=Magdalen College JCR CA/Email=ca@jcr.magd.ox.ac.uk
The common name (CN) should be something like "John Smiths CA", the organisational unit (ou) should be something like "Certificate Authority", the organisation (o) should be you're going to use for your other certificates. Set the email address to the CA contact email address. You'll quite probably want to leave the other fields blank.
Once you've decided on the naming issues, create the CA certificate with:
openssl req -new -key CA.key -x509 -days 1095 -out ../certs/CA.crt
(change the validity time of the certificate as needed). The password you pick should be a very good one, and then guarded well (duh!).

Now, backup your key and certificate somewhere very safe.

You'll need to tell people the fingerprint of your CA certificate. You find this with:
openssl x509 -fingerprint -noout -in CA.crt

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.

Signing certificates with your OpenSSL CA

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.

Firstly, have your user (/ server admin) create their key. Unless you have a good reason otherwise (eg program doesn't support it, program config file is less secure than your key store), you should set a password on the key generated. You should always set one on user's keys, and normally on server keys. To generate a key with a password, use:
openssl genrsa -aes256 -out <new.key>
To generate a key without a protecting password, use:
openssl genrsa -out <new.key>
If it wasn't the user who created the key, then unless you have a good reason then you should delete your copy of it as soon as you've given it to the user.

Next, have the user generate a CSR (certificate signing request), and fill in the fields that will go into the certificate. Make sure you've read the section of an LDAP book on the naming scheme before proceding.
For users, the CN should be their name, for servers it should be the FQN of the server. For users, the email address should be theirs, for the server it should be the email address of the server admin. For users, the OU should be something like "People", and for servers something like "Servers" or "<function> Servers". Generate the CSR with:
openssl req -new -key <new.key> -sha256 -out <new.csr>

Once you have the CSR, you need to make a few checks: that you are happy with the fields in it, you have verified that the person / server it is for really submitted it, you have the correct fingerprints for the key etc. Only once you are happy should you sign the key to give the certificate (the CSR contains the public key to be signed, and the requested fields to go into the certificate). You generate the certificate with:
openssl x509 -req -days 365 -sha256 -in <new.csr> -CA <ssl-base-dir>certs/CA.crt -CAkey <ssl-base-dir>private/CA.key -CAcreateserial -out <new.crt>
(assuming your CA certificate is CA.crt and your CA key is CA.key).

Now, send your user their certificate. If they want it for a browser, they'll probably need to convert it to PKCS#12

Revoking Certificates with your OpenSSL CA
(And telling people about this using CRLs)

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:

openssl ca -gencrl -keyfile ca_key -cert ca_crt -out my_crl.pem

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:

openssl ca -revoke bad_crt_file -keyfile ca_key -cert ca_crt

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:

openssl crl -in crl_file -noout -text
Guides Index
Written By: Nick Burch    Last modified: Sunday, 14-Aug-2016 15:24:47 BST
These pages are from http://www.gagravarr.org/writing/openssl-certs/
Creative Commons License This work is licensed under a Creative Commons License.