Be your own Certificate Authority

OpenSSL allows you do to just about anything related to certificates right up to building your own Certification Authority. While this is technically a relatively simple endeavour, the biggest problem a local CA faces is confidentiality. To be in any way secure, you’ll need to make your CA host as secure as possible. This means you shouldn’t connect the machine to any kind of network whatsoever, install the OS and certificate store on an encrypted volume, store the physical machine in a safe place and tightly control any form of access to said place.

Generate your CA private key

The basis of your CA will be a single self-signed certificate. The private key of this certificate should be treated as a crown jewel. It is the lynchpin in your entire public key infrastructure. Once this gets compromised you’ll need to start over from scratch and consider all your existing certificates compromised.

From your command line you can generate a private RSA key. In the following command you’ll notice a relatively huge 8192 bit key size. Currently it is often advised that 2048 should be enough for anyone. I’m of the opinion that such advice, coming from parties with a vested interest like the FBI and NSA, is not to be trusted. This is why I use 8192 bits for my CA key and at least 4096 bits for any application that will support keys of this size. Sure there’s a performance hit, but it’ll only be there during the initial negotiation and I consider security more important than performance.

The command below generates a key protected by a passphrase, which you will have to enter twice and keep confidential. It would be very wise to protect your CA key with a passphrase. If the file is ever compromised, the key will still be useless without the passphrase. For a CA this property is of great value.

When you start signing certificates for actual use in SSL/TLS negotiations, you may often wish to do without the passphrase. Many certificates are used in automated processes where human intervention to enter the passphrase may be highly inconvenient or even impossible. In such cases you can still use the command below to generate private keys but you should skip the -des3 parameter.

openssl genrsa -aes256 -out ca.key 8192

Based on this key you’ll now generate an actual certificate.The certificate will be valid for 10 years and you’ll need to provide a bunch of data about your organization to personalize it.

openssl req -new -x509 -extensions v3_ca -key ca.key -out ca.crt -days 3650

The command above will generate a self-signed certificate. Answer all the questions as you see fit. Enter the hostname of your CA machine as the certificate’s Common Name. It won’t matter very much if you’re using an isolated offline machine but it’ll never hurt to enter a hostname within your organization’s actual DNS structure. It’s also wise to enter a working e-mail address at it’ll be visible to all those who use certificates signed by your CA. This goes for all of the information here, so refrain from entering random gibberish.

Set up the CA directory structure

An OpenSSL CA requires a few files and some supporting directories to work. It doesn’t really matter where you create these, as long as you are certain they are as secure as they can possibly be.

#mkdir -m 0700 \ 
/root/CA \ 
/root/CA/certs \
/root/CA/crl \
/root/CA/newcerts \ 

The backslashes in the above command denote line breaks. You could type the whole command on a single line but if you do, omit the backslashes. You should move your CA key into /root/CA/private and the ca.crt file into /root/CA/certs.

You’ll also need a small number of initial files inside your CA directory structure.

#touch /root/CA/index.txt
#echo 1000 >> /root/CA/serial

Just to be sure, you should execute the following command to make the CA key read-only to only the system’s root user.

#chmod 0400 /root/ca/private/ca.key

Configure OpenSSL for your CA

Depending on your operating system, you’ll find the OpenSSL configuration file somewhere inside the /etc path. Usually the defaults are alright, but you do need to at least set the $dir variable to your new CA’s root path in the [CA_default] section. Once you do this, OpenSSL will use your CA directory by default. Since this install is for your super-confidential CA, I’m assuming you won’t use the machine for any other purpose so bombing the default config is ok.

Start signing your own certificates

Now that you have everything ready to go, you can start signing your own certificates. You’ll either be handed Certificate Signing Requests (CSR’s) from people within your organization, or you’ll generate them yourself. A CSR consists of some metadata attached to the public part of the certificate-to-be. Your CA’s role will be to sign that key, thereby blessing it for use by anyone who trusts your CA.

Assuming you were e-mailed the CSR as myreq.csr, you should place the file on your CA. Sign it like this:

#openssl ca -out certs/server.crt -infiles myreq.csr

Generating the CSR yourself through OpenSSL can be done anywhere. You don’t need to use your CA machine for this purpose, although it may suit your confidentiality requirements. Generating your certificates on the CA from known-good USB-sticks that only leave your CA machine and never come back can be a sensible policy. At any rate, the command to generate a CSR and a 2048 bit private key goes like this:

#openssl req -new -nodes -newkey rsa:2048 -keyout mycert.key -out mycsr.csr -days 365

Do keep in mind that the private key should indeed be kept absolutely private. The CA doesn’t need it. In fact, nobody needs it except the system which is to be protected by the certificate. A decent practice could be to generate the CSR directly on the machine that is to be protected. You can leave the key where it was generated, only the CSR needs to be signed and the certificate placed back on the system once signed.

So now what?

The instructions above are enough to create your own private protected VPN or wireless WPA2 Enterprise network (your WLAN will be by far the toughest nut to crack in your appartment block). OpenSSL can do a whole lot more and you should definitely look into the documentation that goes with it. The man pages are quite excellent and are a good place to start learning about the more advanced options.

OpenSSL is a veritable Swiss army knife of digital encryption. I consider it a lot more capable than, for instance, the certificates management console in Windows. Just remember that this little guide is meant as a quick-start to a working CA set-up using one particular tool. I cannot emphasize enough that anyone handling serious encryption should thoroughly understand the underlying theory.

There is no silver bullet or an absolute best practice of doing this. There also is a reason why people pay commercial CA’s good money for a few cryptographically signed bits. They make a huge effort to be as trustworthy as possible in their role as a mediator of trust between two parties who would otherwise have no reason to trust one another. Encryption is there because you have something to hide. Don’t take any short cuts with it and read up on the subject before you do anything serious with it. Imagine the disappointment when your plans for world domination leak because of a slightly misconfigured certificate.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.