Sensibility of using generic client keys with openvpn in this scenario

Question

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.

Answer 1

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...).

Answer 2

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.