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 have configured a working openvpn server (ubuntu 10.04) and client, no problems.

I generated certificates and key files and such like for a client machine.

We deploy a number of these generic client machines for data capture, anywhere between 10 and 20 a month. The reason for the VPN is to allow us to remote login for occasional support and monitoring. They send their data home via other means (not the VPN)

I am considering making the client config files generic and using them on all deployed machines (the "duplicate-cn" option on the server side).

My reasoning is this:

  1. The vpn server explicitly disallows ssh login from anywhere except our office, so a connected client cannot ssh into the server
  2. In addition, login to the openvpn server requires the X509 .pem keyfile (it's an Amazon EC2 instance)
  3. The server does not allow clients to see each other ("client-to-client" is commented out), and there is no access to any other networks, it's purely so we can ssh in to the client.
  4. We are lazy, and don't want to admin generating the certs, applying them to the machine (hence no longer generic and no longer hot swappable etc) and people will get confused and get this wrong.

The main drawback seems to be:

  1. It's difficult to tell which machine is which where there are many connections (I haven't found a solution for this yet)

The client machines are installed on "untrusted" sites, that is, I cannot guarantee their phyiscal security.

So my question is... what is the worst that could happen in this scenario? If a machine got compromised directly, the worst it could do is open a VPN tunnel (which it does automatically anyway!) but then could not really get anywhere beyond that. We could just block that IP at the firewall level once detected.

Is my thought process correct here or have I missed anything?

Edit:

I maybe should have said that the client machines are headless (no video/keyboard) and not accessed directly by the client sites (although you cannot outright guarantee that!). This is a machine-2-machine (M2M) environment. These are not (eg) laptops carried by sales folks.

share|improve this question

2 Answers 2

up vote 4 down vote accepted

Do not, DO NOT, DO NOT do this. You are completely defeating every purpose of certificate-based authentication.

  • What you are doing breaks identifiability
    If everyone has the same key pair you can't tell one machine from another.

  • What you are doing breaks security.
    If everyone has the same key pair and the private key gets compromised ALL of your systems' connections are compromised, and everyone's key pair needs to be changed.

  • What you are doing breaks security (again).
    If everyone is using the same key pair you can't revoke a single entity's access by revoking the certificate.
    This may not seem important now, but one day you will need to remove someone's access. Can you be sure they didn't keep a copy of the private key? (Hint: NO - so now you have to change everyone's key again.)


Security is not supposed to be convenient, and does not cater to the lazy. If you want the added benefits of public-key authentication you need to be willing to take on the (slight) additional burden of managing the keys correctly.
If you don't want that additional workload then do as DrGkill suggested and simply configure pre-shared keys (one per party - a generic pre-shared key has all the same problems I listed above for generic certificates...).

share|improve this answer
    
I appreciate your candid response. I understood a couple of the points above and that was what stimulated the question and validated my niggling doubts. In actual fact the inability to recognise the machine is the deal breaker that would drive a solution to the key pair problem. I need to figure out an automated way of generating this during our machine build process and transferring it to the VPN server to avoid humain intervention (and the associated errors) –  Aitch Aug 29 '11 at 18:21

This is a bad thing, Certificates are made to identify people, so the use of one certificate for a bunch of people makes no sense. You could simply configure your openvpn server with preshared keys, which is much more easier to maintain.

Now, imagine that the generic private key is compromised. It means that you have to revoke it and give to all users the new certificate/key to install. You'll make lot of unhappy people making your system unproductive. Plus the fact you'll probably don't know who lost the key.

share|improve this answer
    
AFAIK, You cannot have more then 1 connection with pre-shared keys. –  Zoredache Aug 29 '11 at 16:01
    
@Zoredache - You would need a key/client definition for each machine. Not sure if it would let you use identical passwords, but 99% sure it can be done with discrete passwords. –  voretaq7 Aug 29 '11 at 16:13
    
@Zoredache: putting aside the rights or wrongs of whether you actually should or not for a moment, you can actually do this, it is the "duplicate-cn" option in the openvpn conf file on the server. The comments (from memory) don't suggest it is intended for production –  Aitch Aug 29 '11 at 16:40
    
@Aitch, The duplicate-cn option is for certificate based authentication. OpenVPN has a second mode for pre-shared keys, but AFAIK, that mode only allows one client per OpenVPN daemon. –  Zoredache Aug 29 '11 at 16:43
    
OK, apologies, my mistake, I see what you were getting at –  Aitch Aug 29 '11 at 17:24

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.