Mac VPN certificate: why the identity chooser stays empty
The client needs a certificate with its private key, in a store it reads. Check the identity first, then check whether the gateway accepts it.
You installed the certificate, it appears in Keychain Access with a friendly name, and the VPN client's identity chooser is still empty. The client is not looking for a certificate. It is looking for an identity: a certificate paired with the private key that can prove possession, stored where the client is allowed to read it.
What the client asks for is an identity
Apple's security framework treats a certificate and an identity as different objects. A certificate is public data. An identity is that certificate plus its private key, and only the identity can complete a challenge. A trusted CA certificate, meanwhile, lets a client evaluate an issuer; it does not make the machine the holder of an issued client credential.
| Item | What it can do | What it cannot do |
|---|---|---|
| CA or server certificate | Validate the gateway's chain | Authenticate this client |
| Client certificate without key | Nothing for authentication | Prove possession of anything |
| Identity (cert plus key) | Answer the authentication challenge | Guarantee the gateway accepts it |
That is why importing a .cer file never produces a usable client identity. The file carries public material only, and no amount of renaming or trusting makes it a key pair.
Three reasons the chooser stays empty
The first is a missing private key, which means the enrolment or import process did not deliver one. The second is a store the client does not consult: a user-scoped profile looks in the user's keychain, and an item placed in a system store may be invisible to it. The third is a purpose or policy mismatch, where the certificate exists but is not valid for client authentication under the deployment's rules.
security find-identity -v -p ssl-clientThis lists identities the system considers valid for client authentication. If the count is zero, the problem is upstream of the VPN client and no profile edit will fix it. If the identity appears here but not in the client, the client's store or scope is the difference.
Where the private key lives, and who may use it
When you import an identity through Keychain Access, the import dialog offers a destination keychain. Which destination is correct depends on the client and on whether the profile is user-scoped or device-scoped. An old answer recommending the system keychain is not a universal rule, and copying items between stores is not a repair.
System Roots is a trust collection. Putting a certificate there changes which issuers the system trusts; it does not create a private key, and it is not an identity store. Moving unrelated certificates around to populate a chooser is the kind of fix that leaves a machine with a permanently widened trust set.
Private-key access is a separate control. Granting every application permission to use the key solves one client's selection problem and hands the same capability to everything else on the machine. Grant it to the client that needs it, and check whether the key is hardware-backed or marked non-exportable; if it is, the supported provider has to be used rather than an exported copy.
How the profile points at the credential
In a managed native IKEv2 configuration, the profile references its credential payload through PayloadCertificateUUID. The referenced identity and the way it was provisioned are what matter; editing a display name in the profile does not repair a reference that points at the wrong payload or at one that never delivered a key.
A third-party provider may use a completely different selection mechanism, such as its own store or a system prompt. Read that provider's documentation instead of transferring native-profile assumptions, and verify the reference in the profile that is actually installed rather than the one in the management console's draft.
Selection and acceptance are separate milestones
A populated chooser means the client can find and use an identity. It says nothing about whether the gateway will accept it. The server still checks the issuer, the validity window, the revocation status, and the mapping from that credential to an account.
Test both stages explicitly, in that order. Confirm the identity is offered, connect, and then have the gateway's owner confirm which credential was presented and which mapping rule consumed it. If the client offers an identity and the server rejects it, the remaining work is on the server side. Reinstalling the certificate on the Mac will not change that outcome, however many times it is repeated.