Certificate visible in Windows but OpenVPN cannot use its key

The certificate is visible in the Windows certificate viewer, and the client still cannot use it. Seeing a certificate proves only that a public object exists in a store. It does not prove that the connection process can find the matching private key or is allowed to use it.

Three objects have to line up. The selected certificate, the private key behind it, and the account the client runs as are separate things, and each can fail on its own.

Three objects, three answers

Community OpenVPN on Windows documents a CryptoAPI store selector, cryptoapicert, which takes a thumbprint. The value must identify the certificate you actually intend to use, not a similarly named one. Other OpenVPN-based applications can have a completely different import model, so the selector is evidence only for the build that documents it. Confirm that your client implements the mechanism before debugging anything downstream.

If the build does not support the selector, the fix is a different profile format, not a different certificate.

Does the selector resolve to the right identity

A public certificate can be imported without its private key. The certificate viewer shows it either way, which is why this failure looks like the client ignoring a certificate that is plainly there. Check for the key association, not just the presence of the entry.

A renewed certificate adds a second trap. Both entries can sit in the store while the profile still names the older thumbprint, and the client keeps selecting the identity you meant to retire.

Check which identity the selector resolves to before you look at permissions. A wrong thumbprint fails the same way as a missing key.

Can this account use the key

Key access is per account. A service, a scheduled task and an interactive desktop session can have different store views and different permission to use a private key. The certificate being visible in your own session says nothing about the service account.

A hardware-backed key may need its provider and a confirmation step. A service that cannot show a prompt will not be rescued by exporting the key to a plain file.

Read the local error before changing anything. A selection failure, a signing failure and a remote rejection are three different outcomes. Only the first two are local. The third means the key worked and the server decided against the certificate.

Local use is not remote acceptance

Local success is not authorization. Once the client signs with its key, the server still evaluates the issuer, the validity window, the role and its access policy. A different certificate from the same CA does not automatically carry the same VPN rights.

The server needs the trust chain, not a copy of the client's private key. Sending the key to the server is never the repair for a verification problem.

Work the failure in order

Keep the exact error text. A missing key permission should not turn into a CA change, and a remote rejection should not turn into a store repair. Each has its own evidence.

Work in the order the failure appears: selector, key, account, then server policy. The community client reference documents the Windows store selector for the version you run.