Copying a VPN Certificate Does Not Copy the Key

The walkthrough starts at the client's certificate list, where the entry shows a name, an issuer and an expiry date and nothing else. Export it, import it on the second device, and the connection is refused because the client cannot prove possession of the private key. The file was copied completely; the mistake is expecting a certificate to carry its own key. Read the export dialog before choosing the format, then inspect the file you actually received.

Two clicks, two very different artefacts.

Read the Export Dialog, Not the File Suffix

A DER or PEM certificate export contains a public key and the signed identity claims, which is what a server needs in order to trust you and what a client needs in order to verify a server. A PKCS#12 bundle is a container that can hold a certificate, its chain and the matching private key, protected by a password, though it can also be created without the key.

PEM is only a text encoding, not a promise about contents. The same suffix can describe a single certificate or a file with several labelled blocks, and the export options decide which.

So the useful question is never which extension you got, but which blocks the file contains. A bundle exported without its key is still a bundle. Check the contents rather than the popularity of the format.

Inspect What You Actually Got

Look for the labels before importing anything, then read the certificate fields to confirm which identity you are holding. Run the checks on the file that will actually be imported. Repeat them after any re-export, because the options may differ.

grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -text | head -5
openssl pkcs12 -info -in client.p12 -noout

An export with only a certificate block is a public object and cannot authenticate. A key block with no certificate leaves you without the chain the server expects. The PKCS#12 information output also reports whether a key is present, which settles the question for that format. It names the algorithm and key size too, and it fails outright when no key is there.

Never paste a file containing a private key into a support thread, an issue tracker or a chat, even when it looks like the certificate you were already sharing. Screenshots of a key panel deserve the same caution.

The Key May Live Somewhere You Cannot Copy

On managed devices the private key can sit in the operating-system keychain, a hardware token or a secure enclave, with a policy that marks it non-exportable. The certificate manager then shows the public object while the secret stays put, and no export command will produce a portable copy. Mobile device management enrollment often works this way by design.

That is a control, not an obstacle to work around. Reconstructing a private key from the public certificate is not possible, and any tool claiming to do so is doing something else.

Enroll a New Identity Instead of Copying

The supported path is usually to enroll a distinct identity for the new device and revoke the old one when it retires, so each device can be withdrawn independently. Where an export with the key is genuinely approved, treat the resulting file and its password as credentials: encrypted at rest, transferred over a trusted channel, and deleted when the enrollment is done.

Verify by authenticating with the imported identity, not by watching the import succeed. A client that accepts a public certificate into its store has proved nothing about the key.

Finish by confirming the server accepts the new identity and that the old one still behaves as the policy intends. That completes the walkthrough with evidence, rather than with a file that looks correct.