iPhone IKEv2 Certificate Setup: Manual vs Managed Enrollment

Choosing RSA because the gateway's certificate tool defaults to it is a decision made before the question that matters: how will these iPhones be enrolled? A connection typed in by the user and a configuration profile delivered by management expose different settings, and some certificate choices only exist on one of those paths. Get the order right and the certificate plan becomes short; get it wrong and you issue a credential the phone will not use. Treat the steps below as a sequence, because each one narrows the choices available to the next.

Step one: choose the enrollment path

Manual setup means the user enters the server address, chooses the authentication method and supplies any credential the interface allows. Managed enrollment means a profile carries the address, the identifiers and a reference to a credential payload. The managed path can express combinations the manual screen cannot, which is why the certificate decision has to come after this choice rather than before it.

Both paths can authenticate a phone. They differ in what you can configure and in who owns the identity, so pick one deliberately instead of mixing a managed profile with manual credential entry.

Step two: pick algorithms for the path you chose

For manually configured iPhones, strongSwan's iOS interoperability notes recommend an RSA server certificate, because the manual client may not accept an ECDSA server certificate; the same notes treat macOS separately. Read that as guidance for the supported client set rather than a permanent law about Apple devices. A managed profile has more room: it can select a certificate type explicitly, including an ECDSA client identity, when the payload and the gateway both support it.

Validate the iOS versions you actually support before rolling anything out. A lab phone on the newest release does not describe a fleet that includes older devices, and an algorithm that works in the lab can still fail on the oldest phone in the field. Pull the version range from device management rather than from memory. If the fleet spans releases, test the oldest one first, since that is where the manual interface is most restrictive.

Step three: read the profile fields as separate things

Several similarly named keys describe different objects. The remote address is the host the phone dials. The remote identifier is the IKE identity it expects the gateway to present. The payload certificate reference points at a client credential, and the certificate type field selects the type used for IKEv2 machine authentication. None of those is the CA's signature algorithm, even though the words overlap.

Apple's IKEv2 payload reference lists RSA as the default certificate type with explicit ECDSA variants, and it ties the issuer-name key to particular authentication settings. Read those relationships from the reference for the method you chose instead of copying one key from a working deployment.

Step four: make the gateway identity match its certificate

Use an explicit gateway name such as vpn.example.com and put a matching subject alternative name in the server certificate. strongSwan's Apple guidance also expects the server-authentication extended key usage. Choosing RSA or ECDSA changes none of that: an algorithm cannot repair a name mismatch, a missing EKU or an incomplete chain.

Distributing the trust anchor is a separate task from asserting the identity. The phone needs a certificate chain it can validate, and it needs to be configured to expect the name you actually put in the certificate.

Another platform connecting successfully is evidence about that platform's validation rules, not permission to relax the phone's. Keep the checks identical across clients unless you have a documented reason to differ.

Step five: separate the client identity from the CA trust

A client certificate and its private key are not the same object as the CA certificate the phone trusts. Bundling a CA certificate inside a PKCS#12 identity does not automatically install it as a trust anchor on every supported device, so treat trust distribution as its own step with its own verification.

If the design uses password-based EAP instead, the phone needs the intended account authentication plus server validation. That path does not justify shipping one shared client private key to the whole fleet, which is a different design with a much worse failure mode.

Finish the plan with renewal and revocation in mind: who reissues the client credential, how the profile is updated, and how a lost phone is cut off. Record the profile version and the device versions you validated against, because that record is what makes the next certificate rollover a routine change.