One Certificate per Device Doesn't Make the Key Device-Bound
A per-device certificate is an admin choice, not device binding. What decides binding is where the private key lives, from a copyable file to a TPM.
You issue a separate certificate for each laptop, so you assume the VPN can tell them apart. It cannot. A client certificate proves that whoever connects holds the matching private key, and a copied profile holds that too.
The per-device certificate is still a good idea. It just does a different job than most people expect it to.
What a client certificate actually proves
During the handshake the client signs with the private key that matches its certificate, and the server verifies that signature against the CA it trusts. Nothing in that exchange describes the machine. Any device holding both the certificate and the key produces an identical signature, so a profile copied to a second laptop looks exactly like the original. The certificate names an identity; it does not name hardware.
Uniqueness per device still earns its keep, because it makes revocation precise. It is an administrative property, not a technical lock.
Three levels of key storage
The first level is a key file on disk. It is portable by design, and that is where most OpenVPN profiles live.
The second level is a key the operating system marks non-exportable. Windows can generate a device key in its certificate store and refuse ordinary export, which stops casual copying. It is not hardware-backed, and with enough access to the machine such keys can be recovered, so it raises effort rather than building a wall.
The third level is a key generated inside security hardware: a TPM, a smart card, a SIM or a PIV token. Those modules lack the circuitry to export the key they generated, and signing happens inside the module. The key never becomes a file anyone can copy.
| Where the key lives | Copyable | What it buys you |
|---|---|---|
| Key file inside the profile | Trivially | Revocation granularity, nothing more |
| OS non-exportable key store | Hard, not impossible | Stops casual profile sharing |
| TPM or PIV token | No | Binding the server can rely on |
That table is the whole argument in three rows.
What easy-rsa can and cannot do
Issuing per-device certificates is straightforward. Create a distinct common name per device against the same CA, for example ./easyrsa build-client-full laptop-a nopass, and repeat for each device. Record which common name belongs to which person and machine.
Revocation is equally direct: ./easyrsa revoke laptop-a, regenerate the CRL with ./easyrsa gen-crl, and make sure the server actually reads it through crl-verify.
What the CA cannot do is verify where the private key lives afterwards. If you generate the key on the CA host and copy it to the device, you created a second copy at issuance. A non-exportable key has to be generated on the device, or imported into hardware that will not release it.
Controls that survive a copied profile
Assume the profile can be copied and design around that. Bind the account to a second factor so a certificate alone is not enough. Give each device its own policy so one identity's reach stays limited. And watch for the same common name connected from two addresses at once, which is what a shared profile looks like in a connection log.
Fast, documented revocation is the control that still works after a copy has happened. Everything else is prevention.
The claim the server can actually rely on
Uniqueness comes from the CA. Device binding comes from key storage. Only hardware that cannot export its key turns one certificate per device into a statement the server enforces, rather than a policy everyone agrees to follow.