Why Copying ca.key to Every VPN Client Breaks the CA
A client verifies the CA's public certificate; it never needs the key that signs. Copying ca.key onto every device hands out issuance to whoever takes one.
Somewhere in the setup instructions, a directory gets copied wholesale onto every laptop because it was easier than deciding which files belong there. That directory contains ca.key, and the moment it reaches a second device the certificate authority stops being an authority. Every holder can now issue identities the rest of the network will trust.
The confusion is worth untangling once, because the two files look similar and do opposite things.
Verification material and signing material
A client needs the CA's public certificate to check that the certificate presented by a peer was signed by that authority. That is a verification task, and it needs no secret at all. Signing a peer certificate is a different task, performed once by whoever runs the CA, with the private key that never leaves its protected storage. Keeping those two jobs apart is the entire point of shipping two files.
So ca.crt belongs in the profile and ca.key belongs nowhere near it. The filenames are a convention, not a guarantee, which is why the type has to be inspected rather than inferred from the name.
An architecture with an intermediate CA or an online issuing service is not an exception to this. It is the standard way to keep signing capability away from endpoints while still issuing device certificates at scale.
What a client should prove with its own key
Each device gets its own key pair and its own certificate, signed once by the CA. The client presents that certificate and proves possession of the matching private key, and the server decides whether to accept it. This is the identity that gets revoked when a laptop is lost.
The contrast matters most after a theft. With per-device identities, one exposed client is removed by revocation or peer removal, and the rest of the fleet keeps working.
A leaked authority key cannot be handled that way. Every certificate it ever signed, or could sign, becomes suspect, so the response is a trust replacement rather than a single revocation. That is a project, not a ticket.
| File | Role | Belongs on |
|---|---|---|
ca.crt | Public certificate used to verify signatures | Every client profile |
ca.key | Private key that issues certificates | Protected CA storage only |
| client key pair | Proves one device's identity | That device alone |
Reading a file before copying it anywhere
Two commands tell you which kind of object you are holding without printing any secret. The first names the subject and the CA flag on a certificate; the second validates a key and reports its type. Run both against the files in the bundle you are about to distribute. Anything that validates as a private key does not belong in a client directory.
openssl x509 -in ca.crt -noout -subject -ext basicConstraints openssl pkey -in ca.key -noout -check
If the second command succeeds on a file that is sitting in a client bundle, stop and treat the bundle as compromised. Output that says a key is valid also says it is present, and presence is the whole problem.
Note the other direction as well: a client profile legitimately contains that client's own private key. Deleting every key you find breaks the connection without improving anything, so the object has to be identified before it is removed.
Containing a key you already distributed
Do not assume that deleting the local copy reverses the exposure. Anyone who held the file can have copied it, and the safe assumption is that they did. Follow the operator's incident process and replace the trust anchor, reissuing device certificates under a fresh CA.
Then change the packaging that created the problem. Ship a directory listing with an explicit allowlist of files, keep the CA key on a machine that never joins the client fleet, and record which system holds it.
If the authority must issue frequently, move signing behind a service or an intermediate with a narrow scope and short validity. That way a future mistake exposes a subset of issuance rather than the root of trust for the whole deployment.