How to generate keys for clients whilst keeping ca.key safe

Question

I'm setting up a small vpn service for 10 - 100 expats so they can access normally blocked sites. I would like them to be able to sign up via my website, which upon payment the site will generate their client.cert, client.key and client.conf and perhaps a tp.key and will be delivered in some secure, yet to be decided, method.

The problem is to generate these I need to have the ca.crt and ca.key to hand. The ca.key is supposed to be kept locked up in a ultra secure location offline. Keeping it on my web server seems to be asking for trouble. Since other big vpn providers seem to be able to generate keys instantly how are they doing it whilst keeping the key in a safe place - or aren't they?

Finally I was thinking I should maybe keep the openvpn server and the signup website on different servers - is that necessary?

Answer 1

I manage quite a few PKI services so this one is a familiar conundrum.

Wherever possible, we store CA keys on a standalone machine. This is internal to our company network and hosts limited, if any, services. The request and signing processes are abstracted from each other by way of a simple protocol and a bit of manual button pressing. Over time the solutions we've used fall into two camps:

• Something as simple as an HTTPS POST that sends the CSR to an internal resource, prompts for a password and returns the CRT data back out.

• Bespoke and slightly more sophisticated one-way APIs for pulling requests down and pushing the certificates back out. Which actually consists of a triad of systems each broken down to perform a very specific part of the PKI lifecycle - end user collection point, license management and signing.

Frankly I wouldn't advise following the latter unless you have a lot of time or a good business case. You could replicate something like the first. Alternatively, as womble says, you might find that your scope doesn't even warrant that; if you are confident about your web service and decide that damage wouldn't be far spreading.

One such reason that damage wouldn't be as relatively far spreading is that your current plan includes creating client private keys yourself. This suggests that should the web server become compromised, even without the CA key present, that somebody would have access to valid client certificates and associated private keys with access to your services anyway. Which might well precede making your CA secure. Ideally clients should create and be responsible for their own private keys.

Answer 2

I have a sneaking suspicion that the big CAs that provide "instant" SSL certificates are probably either relying on a 24x7 low-paid support person, or (more likely) just putting the CA key on a machine with extremely limited connectivity and only allowing a very simple protocol in to request certificate generation.

Given that, in your case, you're generating a certificate that's only valid for your site, and you've got a relatively small number of certificates to reissue should the worst occur, I'd be inclined to either leave the CA key on the web server (if you're pretty confident that your system security is strong) or have a second machine that's well-secured (no services running other than SSH to provide the key-signing command to the web server) if you're not so sure about the web server security.