Android IKEv2: the user certificate and the CA do different jobs
One field proves who the phone is, the other decides which gateway to trust. Android's IKEv2 profile keeps them apart because the handshake does.
An Android IKEv2 screen asking for both a user certificate and a CA certificate looks like it wants the same thing twice. It does not. IKEv2 authenticates both peers, in both directions, inside the same exchange, and the phone plays a different role in each direction: it has to prove who it is, and it has to decide which gateway it believes. A user certificate answers the first question, a trusted CA answers the second, and neither can stand in for the other.
Two directions of authentication in one exchange
IKEv2 establishes a control channel in two phases. The first exchange negotiates algorithms and keys; the second, IKE_AUTH, carries one AUTH payload from each side along with each side's identity. The payload is a signature or a MAC computed over the exchange, and it is verified against something the receiver already trusts.
The gateway proves its identity with its own certificate, and the phone validates that certificate's chain up to a root it is willing to trust, then checks that the identity in the certificate matches the gateway it intended to reach. The phone proves its identity with its own credential, and the gateway verifies it against the CA that issued the client certificate.
That is the whole mechanism behind the two fields. The user certificate is a statement the phone makes about itself; the CA field is a statement about whom the phone will believe. A profile that has one but not the other cannot complete mutual authentication, and no amount of retrying changes that. The two failures even look different: a missing user key stops the phone from producing a signature at all, while a missing trust anchor stops it from accepting the gateway's certificate.
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
What the Android profile builder asks for
Android's IKEv2 profile builder exposes each authentication method separately rather than as one "certificate" mode. The digital-signature method takes a user certificate, a private key and a server root CA. The other methods take a username and password, or a pre-shared key.
Read that signature closely, because it encodes the mechanism above. There is no field for the user's private key in the username/password method, and no field for the gateway's trust anchor in the PSK method, for the simple reason that those methods prove different things. Mixing them by pasting a password into a certificate field produces a profile that fails at IKE_AUTH with a message that names neither.
The documented private-key type for the digital-signature method is RSA. A menu labelled "IPsec" or "certificate" does not imply ECDSA support, and a profile assembled on the assumption that it does will fail at the platform API before the network is even involved.
Why a public user certificate alone is not enough
The AUTH payload is a signature over the exchange, made with the client's private key. Possessing the public certificate lets the gateway check a signature; it does nothing for the phone, which needs the key to produce one. Importing only the .crt and leaving the key behind is the single most common version of this failure.
Android's key infrastructure reflects that. Selecting a client identity goes through KeyChain, which requires access to the corresponding private key, not just a certificate entry. An enrolment package or device-management workflow that installs the pair together is the normal way to get a usable identity; copying a certificate file by hand usually is not.
So the two items in the profile are not a certificate bundle and a duplicate of it. One is a key pair the platform must be able to sign with, and the other is a trust anchor the platform compares against. Check them as two separate facts: can this profile sign, and does it know whom to trust?
Trust anchors belong to an application, not to the phone
Installing a root certificate in the user store does not make every Android application trust it: since Android 7 an app has to opt in through its network security configuration, and before that release user-installed CAs were accepted far more broadly. Application trust configuration can differ, and a VPN client that manages its own trust material may never look at the user store at all. That is why the same CA file can work in one client and appear to be ignored in another.
Two ownership models follow. A system-managed VPN profile uses the device's certificate installation or administrator enrolment workflow, and the profile then references the intended CA. An app-managed VPN keeps its own trust material and uses its own documented import, which may be completely separate from the Android settings screen. That is also where you repair a broken chain: in the CA store and profile selection for the system-managed case, in the client's own import screen for the app-managed one.
Decide which model you are in before importing anything, then confirm the active profile's trust selection afterwards. If the operator's instructions and the client's menu disagree, the client's documented behaviour wins for that installation, but the CA must still come from the operator through a channel you can verify. A file's name is not evidence of who issued it.
Choose the mode, then the files
Certificate mode needs a client key pair, the issuing CA on the gateway side, a trust anchor for the gateway certificate, and an expectation of which identity that certificate must carry. Username/password mode replaces the client key pair with credentials but keeps the gateway trust requirement intact. PSK mode replaces both with a shared secret and changes the trust model rather than simplifying it.
Whichever you pick, keep normal validation enabled. A "don't verify" option, where a client offers one, removes the check that the CA field exists to perform; it does not fix a missing trust anchor. The same applies to accepting any server certificate because the connection works without it.
Then verify in the right place: import the material, connect once, and confirm in the client's connection details that the gateway identity is the one you expected and that the profile reports the authentication method you intended to use. A successful connection with the wrong method selected is a configuration you do not understand yet, and it will fail the next time the operator tightens a policy.