Why cryptoapicert Fails in OpenVPN 3 and Connect on Windows

You copy a working OpenVPN 2 profile into a newer Windows client, and the certificate the old client found by itself is no longer offered. The line that made that work is a Windows-only selector belonging to the Community 2 client, and the newer application is a different program with a different credential path. The profile is unchanged apart from that one line, which is exactly what makes the difference hard to see.

Three layers get conflated in that report: the Community client, the core library, and the frontend somebody installed. Only one of them ever understood the directive.

What the option means where it exists

In the Community OpenVPN 2 client on Windows, cryptoapicert names a certificate the client should locate in the Windows certificate store rather than in a file. It is a Windows-specific convenience, and it works because that client knows how to enumerate the store and hand the resulting key to its own TLS stack. The directive is therefore part of that client's configuration language, not a property of the OpenVPN protocol. Nothing in the wire format carries it.

Copy the same line into another application and you have copied a word that the new program may parse, ignore or reject. A directive is not a protocol feature, and this one is not even a feature of every client that speaks OpenVPN.

What the core library exposes instead

OpenVPN 3 Core is a library that other applications embed, and it handles external credentials through an API rather than a store lookup. The embedding application supplies a certificate chain and, later, asks the library to sign with an external key, and the library calls back into the application to do it. That is a more general design, and it means the frontend decides which providers exist. In the core's own option handling, cryptoapicert appears among the directives that are not implemented, which is consistent with that division of responsibility.

The existence of those callbacks does not mean a given packaged application enumerates the current user's personal store, supports a particular key provider or can complete a smart-card prompt. Those are frontend properties, and each has to be documented by the frontend.

What the Windows frontend does instead

OpenVPN Connect takes a different route: the operator imports a PKCS#12 file containing the certificate and its private key into an OpenVPN Certificate Store created for that purpose, then assigns the external certificate to the profile. That is a deliberate import step, not an automatic discovery of whatever happens to sit in the personal store. The distinction matters when somebody assumes a certificate installed for another purpose will simply appear in the client's list.

The import also has a consequence for key policy, because exporting a key into a P12 file is exactly what a non-exportable key is designed to prevent. That is a policy question rather than a configuration one, and it deserves an answer before anyone attempts the import.

Choose a path that matches the key's policy

If the credential is exportable and policy allows the documented import, use the organisation's protected enrolment process and keep the temporary P12 and its password out of logs and scripts. If the key must never leave a smart card or a protected provider, choose a client and provider combination that explicitly supports that requirement, or get confirmation from the vendor for the version you installed. Neither branch is a workaround for the other.

Adding the directive back to the profile cannot supply an integration the application does not have. Nor does a newer client version necessarily add it, because the capability belongs to the frontend's own design.

Once the local key works, the server still checks the certificate identity, the chain and the authorisation. A usable local key and an accepted VPN identity are separate outcomes, and keeping them separate is what stops a frontend limitation from turning into a weakened certificate policy.