Why OpenVPN Still Asks for a Private Key File With a Token

You plug the token in, the vendor's own tool sees it, and the VPN client still asks for a private-key file. That prompt is not evidence that the token is unsupported. It usually means the profile never told the client to use the token at all, so it fell back to the certificate-and-key inputs it expects by default.

Two separate values have to be right before that fallback stops: the provider that exposes the token, and the identity of the certificate inside it. They are supplied by different options and are easy to conflate.

The client asks for a file because the profile says to

A default profile expects a certificate file and a private key file, or a single PKCS#12 bundle. When those inputs are missing the client has nothing to load and behaves much as it would for a missing file, which is why the symptom reads as a broken path rather than a missing mechanism. The PKCS#11 path replaces those inputs rather than supplementing them, so a profile that still names a key file will keep using the file. Remove the file inputs deliberately and let the token supply both halves.

The provider option names a middleware library, not a device and not a certificate. Whether a packaged client can load that library depends on how it was built, including optional p11-kit support that some builds enable and others leave out. A generic tutorial cannot tell you which arrangement your package has.

The serialized identity is a different value

The certificate identity is a long serialized string produced by the discovery process, and it is not the library path, the token PIN or the VPN account name. It often contains characters that need quoting, and an unquoted value can be truncated or misread without a clear error. Use the client's own identity discovery option to list what the token exposes, then copy the intended entry exactly. Selecting the first object in the list is how a device ends up presenting the wrong certificate.

The discovery output also answers a prior question: whether the token is visible through that provider at all. If it lists nothing, the problem sits upstream of the VPN client and belongs to the middleware.

The process that connects must reach the token

A token operation that works in your desktop session proves nothing about a system service. The service may run as another user, in a different mount namespace, with a module path that omits the vendor library, or without permission to open the device node. Identify which process actually holds the connection and test from that context.

PIN handling deserves its own decision. The reference implementation offers a PIN cache and a protected authentication path, and both exist so an operator can choose a workflow instead of inventing one. Do not convert an unattended requirement into a plaintext PIN inside a shared profile, because that trades the token's protection for convenience. Where the token forbids key export the signing happens on the device and the PIN is the only local secret. Treat it with the care that implies.

What the token does not replace

The token authenticates the client under the deployed policy, and it does not replace the client's checks on the server. A successfully selected certificate is not permission to accept an unexpected gateway certificate, and the two verifications protect opposite directions.

Enrolment still has to happen at the issuer, and the gateway still has to authorise the identity.

For acceptance, separate the stages: the provider loads, the intended certificate is found, the private key is used with local authorisation, the VPN authenticates, and the resource operation succeeds. Stop at the first stage that fails rather than cycling through passwords and reinstalling the crypto stack.

Record versions, module ownership, the selected public identifier and sanitised errors, and leave PINs and credential bundles out of that record.