Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers 2

up vote 3 down vote accepted

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.

share|improve this answer
    
thanks for the input, when i said id fetch the cleint certs and keys back to the webserver from the sercure key generating server i failed to mention my full plan. I thought whatever delivery method i chose to get the files to my clients, the cert and key would be deleted within a timeframe e.g. 24 hours. If i could safely deliver via email then Id delete them off my webserver immediately after sending them. Whilst not perfect it should help tp prevent damage....right? or is that ultimately flawed? –  adam Oct 6 '09 at 15:07
1  
It isn't ultimately flawed. But it also isn't fireproof. Having users create their own private keys and submitting requests, which will then be signed and returned as certificates, ensures that the only time a certificate and key are in the same place and usable is when they have finally arrived at the end user. The signed certificate by itself on the webserver is of no use without the corresponding private key. –  Dan Carley Oct 6 '09 at 15:28
    
thanks. That leads me to the question of "how do i get the client to create their own keys". Ive asked this question here though serverfault.com/questions/72089/… –  adam Oct 7 '09 at 9:47
add comment

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.

share|improve this answer
    
i did think it might be something like this. So my webserver would ssh to the secure server which hosts the ca.key and various cert/key builing scripts, fire them off and then fetch the generated client keys back to the webserver for delivery to the client? is that right? –  adam Oct 6 '09 at 13:28
    
That's about the strength of it. –  womble Oct 7 '09 at 3:13
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.