Does an iPad Need Its Own VPN Client Certificate?

New iPad joins the team, and the fastest path is to export the existing client certificate and install it on the tablet. That works until somebody leaves, loses a device, or asks for an audit that says which device connected when. The decision is not about the certificate file but about identity: whether each device can be authorised and revoked on its own. Cost and management effort decide the answer, and both are smaller than they look.

Shared Issuer, Separate Identities

Every device can trust the same certificate authority and connect to the same gateway while holding a different client identity. The issuer is a trust anchor, while the identity is a key pair whose subject the server maps to a policy. Conflating the two is what makes a shared certificate feel harmless. It stays harmless only until somebody needs to know which device opened a session.

Sharing the issuer saves configuration work and changes nothing about per-device accountability. Sharing the identity collapses every device into one revocable unit: revoking one revokes all, and authorising a replacement authorises every copy of the key that was ever made. That trade is worth making explicitly rather than by copying a file because it is quicker on a Friday afternoon.

When a Second Certificate Costs Too Much

Per-device enrolment costs a step: a managed payload, an SCEP request, or a guided import with a one-time password. It also costs a place to track serial numbers and expiry dates, which is the part most deployments forget until the first certificate lapses. Both costs are one-time, and both shrink once the enrolment flow automates them.

The cost is real for a household with two tablets and one user, where a shared identity is a reasonable decision documented in one sentence. It is not reasonable for a service where access must be withdrawn per person or per device, because the revocation story is the entire reason to use certificates instead of a password. Judge the deployment by how often devices change hands, not by how many devices exist today.

Enrol the Device, Do Not Copy the Key

Modern platforms keep private keys in a protected store, and some mark them non-exportable by design. That property is what makes copying impossible in the first place, and it is also why an exported bundle from a laptop cannot simply be re-imported on a tablet in any supported way. Attempting it anyway produces a profile that installs cleanly and then authenticates never.

Use the enrolment method the deployment already supports: a managed identity payload, a SCEP service, or an account-based flow that issues a new key on the device. Distributing the certificate authority's private key to solve a missing identity is a different mistake with a far larger blast radius. The authority issues credentials and should never travel to the endpoint.

Check Revocation Before You Answer

Before choosing the shared option, describe what revocation looks like on the worst day. If the answer is one action affecting several devices, the design has already decided against you.

openssl pkcs12 -in client.p12 -info -noout
openssl x509 -in client.pem -noout -subject -issuer -serial -dates
openssl verify -CAfile ca.pem client.pem

Inspect the material you actually hold: whether a private key is present, what the subject says, and whether the serial can be revoked individually. A certificate file without its key cannot authenticate anything, which is why some copied identities fail at the first connection.

Deleting an app from the tablet is not revocation, and the server keeps accepting the identity until somebody disables it. Write that sentence into the runbook before the first device is enrolled.