edit

Going SSL with your own Root CA

Posted by Christopher Wojno Wed, 05 Nov 2008 04:06:00 GMT

The Prompt

Recently, my slew of SSL certificates expired for my site and e-mail. Like most people, I didn’t write anything down when I set it up. After all, I was just trying to explore what I could do with my server at that point. So, I decided to make my own Root CA for my site’s certificates. That way, my family and I can use my root certificate to verify the authenticity of my servers and services.

What are you talking about?

SSL Certificates. SSL/TLS is the secure socket layer. It uses the PKI (public key infrastructure) to provide both data encryption and confidentiality. You can review the Wikipedia article about PKI and SSL

Anywho, with a fully working SSL/TLS system in place, you can be relatively sure that your client-server (and server-server) communications are not only encrypted, but being held between the party with which you believe you are communicating. This means you can use your e-mail and web server on a public network and not worry about your password being sent in the clear or digested format. It also means you’re sure you’re talking with your servers and not someone pretending to be a gateway. It’s nice, but it’s much more complicated to set up.

One of the problems with self-signed certificates is that you are not sure if the certificate is authentic the first time you connect to the server. As I have SSL for my mail and https server, I’d have to independently verify each certificate via the SHA1 hash and identifying information to be absolutely sure my communications are secure.

Where does the Root CA Thingy come in?

A CA is short for “Certificate Authority.” A Certificate authority can sign certificates that you make. Because the CA is trusted, when the CA signs your certificate, it transfers that trust to your certificate. When you get your operating system (or your web browser or e-mail client), there are several Root CA’s pre-installed. They pay lots of cashey money to be there so that your browser, operating system, and e-mail client will recognize theirs and certificates they sign as trusted.

OK, so How do you do it?

Disclaimers

This guide is for amateur, non-production use only. I make no warranties or guarantees as to the correctness of this document. This guide involves escalating privileges and may cause irreparable damage if used improperly. You use this document at your own risk and I hereby disclaim any responsibility or liability for your actions or non-actions.

Overview

1. Create a “proper” and “secure” environment for your CA private key and certificates
2. Create a CA private key
3. Create a CA Certificate Signing Request (CSR)
4. Self-sign the CA CSR using the CA’s private key thereby creating a CA Certificate
5. Install the CA Certificate locally

Create a “proper” and “secure” environment

Before we begin, we need a “secure” place to put our CA Root’s private key. We cannot let this fall into the wrong hands (or any hands other than ours).

When you see YOURUSERNAME, replace it with the username you use to access the system onto which you are creating the Root CA’s certificate.

sudo mkdir /usr/local/etc/certificate_authority
sudo groupadd ca_admins
sudo usermod -a -G ca_admins YOURUSERNAME
cd /usr/local/etc/certificate_authority
sudo mkdir certs
sudo mkdir private
sudo chmod 0770 private
sudo chmod 0775 certs
sudo chown :ca_admins private
sudo chown :ca_admins certs

You’ll need to log out and then log back in to properly join the ca_admins group. Be sure to cd to the /usr/local/etc/certificate_authority directory when you do so. The following steps assume that you are in that directory.

We’ll be generating the certificate’s private key. It’s important that it never be exposed. I highly recommend that you encrypt it now, when it’s being created, but in this example, I will not do so to facilitate this demonstration. I’ll indicate where you’ll need to put in the encryption.

I’ve created an environment that is relatively “secure.” That is, it is only as secure as your server. We will generate the private key in the private folder. I have designated this as readable only to root and members of the ca_admins group. I’ve also put commands in to create that group and have you join it.

When you create the CA private key, it will be placed under “private.” When the certificate is generated and signed, the resulting certificate will be placed in the certs directory. The only file that needs to be kept secret is the CA private key. We generate it in the next step.

The proper location for local configuration changes should be the /usr/local/etc folder. It’s a toss up as to whether or not a CA’s private key is a local configuration resource. It may be better to place all of this in the /var/local/certificate_authority. The serial file most assuredly belongs here (created later) as would a Root CA CSR configuration file (not used in this document). However, for the purposes of this document, we’ll keep it as is.

In this step, I’ve also created a certs directory and a private directory. Certificates that we create for the CA Root should be placed in the certs folder. The private key for the CA Root should be placed in the private directory, as it will not be world-readable.

The CA Private Key

I like RSA certificates, so I generate RSA server private keys.

openssl genrsa -out private/cakey.pem 2048

If you want to create an encrypted key, specify this:

openssl genrsa -out private/cakey.pem -des3 2048

and you’ll be asked to specify a password for your new key. Do NOT lose this password. You’ll never be able to get this key back. That means you can’t sign or create your certificate.

Create a CA CSR and Sign it (single step)

openssl req -new -x509 -key private/cakey.pem -out certs/cacert.crt -days 3600

This creates a 10-year (abouts) certificate signing request that is immediately signed by the CA’s Root private key to produce the certificate (certs/cacert.crt). We’ll be using it as our Root CA certificate. If you put a password on the key, you’ll be asked for that password again. You’ll also be asked a series of questions to identify your certificate. Answer them honestly. When you get to the CN field, do NOT enter your domain name or similar. Name it something that’s impossible to be a domain and does not conflict with another Root CA. I called my “Wojno CA Root” modeled after Apple’s certificate name: “Apple CA Root”.

You now have a real certificate. Now you need to install it locally onto every machine that will use a certificate signed by this Root CA Certificate. Yes, this is bothersome, but it sure beats having to specify an override for every certificate you generate. It also lowers the risk of accepting a bogus certificate by your users, in the event you miss one or more.

Installing the CA Certificate locally

This process varies between operating systems and/or browsers. Apple uses the Keychain. Windows has a root certificate listing in the Internet Options panel (accessible via the control panel). I have no clue where it would be in Vista. You’re on your own there. Once you have it installed, you’ll be able to create as many certificates and sign them and all will be automatically trusted because you now trust the Root CA Certificate that will sign them all. Special note: do NOT install stranger root certificates! This will pose a security risk if you go about installing root certificates willy-nilly.

Create the serial file

Back in your ca directory where you created the private and certs folders:

echo "01" > serial.srl
sudo chmod 0660 serial.srl
sudo chown :ca_admins serial.srl

Certificates issued by this CA will be imprinted with a serial number. Every time you sign a certificate, the serial file will be incremented and updated. Only ca_admins will be able to modify or read this file. While hiding the contents of this file is not absolutely paramount, the less that is known, the harder it is to break something (this is a generic statement and not necessarily true, but is usually true).

For use with Apache2’s mod_ssl, please see the next article in the series.