my so-called blog (redux)

I set up my own certificate authority a few days ago. This is not something most people have a need to do, but it’s pretty handy if you end up setting up lots of development sites on new IPs and whatnot, or if you’re deploying services that aren’t going to be used by the general public but still need SSL authentication. Having your own CA means you can properly set up SSL for these kinds of resources without having to pay your CA of choice for a real certificate. If you find yourself creating a lot of self-signed certificates, having a CA also means it’s easier to get your client base to trust your certificates: typically, depending on which Google hit you click on, your average self-signed certificate is signed in a sort of one-time-use way. If you have your own CA, then all your self-issued certificates are signed by the CA - so you can install the CA’s root certificate into your OS’s or app’s certificate repository and be done with it.

For this, I mostly used the instructions from G-Loaded verbatim - I changed some paths to work with my environment. The scripts below are new, though.

(This is a pretty long post.)

Preparing

The CA is simply a machine with OpenSSL on it. This can be anything that OpenSSL will compile and run on. How secure you make it depends on what you’re using the CA for. You might not spend as much time setting file system permissions for one for just you or just a handful of people or one-off dev sites.

The CA exists only really to apply special bits to certificate requests, and so doesn’t really need a server, or any sort of server software on it. You might find it handy to have a web presence somewhere to distribute the CA’s root certificate if you’re handing it out a lot, though. Your CA can exist on a real server or on a workstation, depending on your needs. Most Unixy OSes nowadays come with OpenSSL of some sort included; Windows does not, but there are ways to get it. (Windows Server users also have the option of adding the Certificate Authority role to the server, which won’t be covered here.)

(The scripts below assume a Unix machine with bash installed.)

Organization

If you’re not a fan of organization, you can skip this step. Creating and signing certificates creates a lot of text files, though - you have 3 at least for each certificate (the request, the key, and the certificate itself), and there are some databases and the CA certs and keys as well. I set mine up this way:

private/
certs/
newcerts/
reqs/
crl/

private is where keys are stored. certs is where signed certificates are stored. newcerts does the same thing as certs, but OpenSSL, when signing, will also write a copy of the cert with its serial number to this folder. reqs is where certificate requests end up. crl is where your certification revocation list is (which I’m not going to get into here).

Of these folders, it’s very important to have strict permissions set up on the folder where you actually keep the keys. The server keys that’ll be created if you follow these instructions will have no passphrase - good for unattended server startup, but bad for security, as anyone can create a req with your key if they get a hold of it. The other folders aren’t as important; they just need permissions appropriate for your environment. (Mine are group read/write and others read-only; I only want certain people to be able to sign certificates.)

You can also create another folder for OpenSSL support stuff, as you’ll have a couple database files and the configuration file for OpenSSL (separate from the system one). The folder names themselves are arbitrary; if you want to change them, feel free to. You’ll have to remember what you did when you work in the configuration file and the scripts, though.

Setting up the CA

The first thing to do is to set up the folders for the CA. Move to the folder that you want to store the CA’s files and make folders based on how you want to organize everything. If you’re using my example above, the command (on a Unix machine) is:
mkdir -m 0755 private/ certs/ newcerts/ reqs/ crl/

(You’ll want to specify a decent set of permissions on the folders; 0755 will give you read/write/execute access and everyone else read/execute. In my case, I actually did 0775 and chgrp‘ed the folders to the group that can manage certificates.)

Once you’ve got the folders set up, you’ll need to create a CA-specific OpenSSL configuration file. Usually, this means just copying the system one and modifying it. On Mac OS X, this is in /System/Library/OpenSSL, but for most other systems, it’ll be in your /etc somewhere. If you’ve installed any third-party distribution of OpenSSL, or compiled your own, use the conf file from there. The file itself is called openssl.cnf.

Your config file should just be readable by people who can manage certificates, so set this either 0600 or 0660. You can name it anything you want; I left mine as openssl.cnf. You’ll either specify the exact name of the CA-specific config file or use scripts that have it built in.

You also need to make two files: one holds a database of certificates and one contains the serial number of the next certificate.
touch index.txt ; echo '01' > serial
will get these two done. (Make sure you change the paths if you’re storing the database/housekeeping stuff in its own folder.)

The next thing you need to do is create a key and a self-signed certificate for the CA itself. From within the CA’s folder:
openssl req -config openssl.cnf -new -x509 -extensions v3_ca -keyout private/certauth.key -out certs/certauth.crt -days 1825

Change the -config option to whatever your CA-specific config file is. You can also change the -keyout and -out options as well if you’re putting things into different folders. The -days parameter is set to 5 years; you can adjust this as you see fit.

You’ll be prompted for a password when you do this; make sure you choose a good password for this. The information that OpenSSL will ask you for can be anything, but you should make it as descriptive as possible. (Specifically, the Common Name can be anything - this is just for the certificate authority, so it doesn’t have to correspond to a specific server hostname.)

When it’s done, make sure you remove all permission but read from the key - in the example above, private/certauth.key. If people get the key and your password, they can act as you, so it’s important to keep these files safe. Keys never expire, so you shouldn’t have to replace it unless you forget the password. The certificate file - private/certauth.crt - can be distributed as you see fit.

The final step is getting people to trust your certificate authority. This is probably the easiest step - you just need to take that certificate you just created and install it on client machines, or make it available for people to install on their own. For the most part, on Windows and Mac OS X, you can just copy the certificate to the computer and double-click on it to install. This is pretty much a follow-the-prompts kind of thing.

One thing to keep in mind is that alternative browsers may or may not use the system-provided certificate store - Firefox, notably, does not. If you’ll be using the CA to sign certificates for Web servers, you’ll want to make sure you install the certificate into any third-party browser you might use as well as into the system itself.

If you made it this far, you now have a properly functioning certificate authority. Yay!

Check back tomorrow for how to actually use your new certificate authority.