Send a VPN Bundle to the Right Recipient, Not Just a Key

A partner sends a public key and asks for an encrypted bundle. The encryption will work, and it may deliver a perfectly protected credential to someone who should not have it. Secrecy and recipient identity are different questions answered by different mechanisms. Answer both before the bundle leaves your machine.

Two different questions: secrecy and recipient

Encryption answers who can read the file, assuming the key belongs to the intended person. A signature answers who produced it, and says nothing about confidentiality because a signed file can still be readable. A fingerprint identifies a key, and only an independent check ties that fingerprint to a person or role. Treating any one of these as the others is the usual failure in a handoff that looks careful.

The file also has a lifecycle: a link that expires limits later retrieval, but it does not revoke a credential that has already been downloaded.

Verify the fingerprint out of band

Get the expected fingerprint from a channel that does not depend on the message asking you to encrypt. Then compare it with what the local keyring holds.

gpg --fingerprint [email protected]
gpg --list-keys --with-fingerprint [email protected]

The fingerprint lines are the value to compare, and the second command shows the same identities with their full fingerprints for a second look. Confirm the complete string through a call, a signed inventory or a managed enrollment record; a familiar display name proves nothing. If the key arrived in the same message that requested the delivery, its fingerprint is not independent evidence. Import the key only after that check, and encrypt to the verified fingerprint rather than a name.

Deliver only the material the device needs

Inventory the bundle before choosing a transport. Public gateway settings and a public trust certificate are configuration, a client private key is a secret, and an issuer's signing key is a different asset entirely. Where the enrollment model allows it, keep the private key on the device and deliver only what completes enrollment. A VPN client does not need the CA's signing key to validate a server, and one shared live key across partners makes individual revocation impossible.

Sign the artifact as well when the recipient must detect substitution, and keep the two operations separate in the instructions. Keep a multi-file bundle in one archive so the recipient cannot install half a configuration and then report that the gateway rejects the identity.

Close the lifecycle after delivery

Record the recipient, the device, the configuration revision and the revocation route, but never the private value itself. Confirm that the intended person can enroll and that a different identity is refused. If the bundle reaches the wrong hands, replace or revoke the accepted secret through its issuer, because deleting an attachment invalidates nothing that was already downloaded. A password-protected archive whose password travels through the same conversation is not an independent check either.

A handoff is finished when the right identity is active on the right device, not when the encrypted file uploads successfully.