November 2, 2009

There are several good tutorials on how to set up a certificate authority with openssl, but once you have one in place, what is a good way to manage it? Sure there are some tools out there that can help, but I’ve found them all to be a bit of a pain, especially when it comes time to renew a bunch of user certificates. For this purpose, a home-grown script is almost always better than a generic tool. Scripting allows you to customize each and every step of the process according to your specific organization’s needs. In this article I’ll give an example of how I use simple scripts to make key generation and regeneration easy.

It’s worth noting that lots of people probably don’t need their own CA. Generally, using a self-signed key or getting a key signed by a recognized authority will be simpler and easier, but in some cases this isn’t true. For example, at my office we have a server that is accessible via the Internet and contains proprietary information. It’s behind a solid firewall and is pretty well protected. The server is restricted to SSL only, but if username/password systems are used, they constantly get hammered by idiots looking to log in. By restricting the server to sessions authorized with an SSL key signed by our local CA only, we can limit the users that connect. Note that if we used a recognized authority (Versign et. al.) instead of our own, then we would still have the same problem. By using our own CA, no other keys will make it past the SSL authentication stage. We noticed a 86% drop in hack attempts two weeks after we went to this setup on this particular server. YMMV. Note that by doing this we also gain the advantage of users not having to enter their passwords every time they access the server, and the system admin (me) doesn’t have to worry about whether or not users are circumventing the strong password requirements (see my previous post: Subversion, SSL and Apache for Secure, Passwordless, User-based repository access controls.)

It checks to make sure a username is present, and then runs through the three openssl commands necessary for generating the certificates.

Now, as you can see in the openssl.cnf file, the user keys only last for 365 days. So every year we have to regenerate all the keys, most of them on the same day. To do that, we use a perl script: regenerate-all-user-keys

And finally, output the pcks12 formatted certificate to send to the users. Note that the output is encrypted with a passcode postpended with the username. This is sufficient for our needs, but probably not everyones. To make it so that each user gets a unique password, remove the -passout parameter and the sytem will prompt each time it goes to export a pkcs12 certificate.

Pretty straight forward, and makes regenerating hundreds of keys on a single day much less of a problem. A task left to the reader is to have the script email the user their new key based on the e-mail address captured in the subject line. Our doesn’t do that because we have to get VP level approval to send automated e-mails.