IKEv2 Certificate SAN: Why the Identity Check Fails

Your certificate chains to a trusted CA, the dates are fine, and the peer still refuses to complete phase 1 with an identity error. Reachability and a valid signature are only half of what an IKEv2 client checks. The other half is whether the identity it expects appears in the certificate in the right field, and that expectation is set by the profile, not by the certificate filename.

The symptom is always the same shape

A connection profile is changed from a hostname to an IP address, or renewed from a certificate that carried a DNS name to one that carries only addresses, and the tunnel stops negotiating. Nothing in the network path changed. The client reaches the peer, receives a certificate, and rejects the peer identity because the identifier it was told to expect is not represented in a field it accepts. Renewals are the usual trigger, since the replacement certificate often comes from a different template than the one it replaces.

Both sides then log something unhelpful, which is why the failure usually gets reported as a certificate problem. The client log may name the identity it wanted, and that name is the clue you want, not the expiry date.

Match the identifier type, not just the value

A dNSName SAN and an iPAddress SAN are different fields with different matching rules, so a certificate carrying 203.0.113.10 as a DNS string does not satisfy a client expecting an IP identity. Modern validators largely ignore the common name, so the friendly label in the certificate details proves nothing about what will match. If a hostname was replaced by an address during troubleshooting, assume the expected identity moved with it until you have checked. Compare the string in the profile against the string in the SAN character by character, because a trailing dot or a stray space is enough.

Wildcards are a DNS-only convenience and follow their own matching rules, which is another reason an IP-based profile should never rely on them.

Find where each client stores the expectation

In strongSwan, the value compared against the certificate comes from the peer identity setting: rightid in the classic configuration, or the id of a remote connection section in swanctl. Its documentation on Apple IKEv2 interoperability is useful here because it spells out the identity conventions a profile-driven client uses, and those conventions explain a class of mismatch that looks random on the wire.

Apple configuration profiles carry a remote identifier field, and the value there is what the client checks rather than the server address in the connection settings. Windows and appliance clients each have their own field with their own default, and the default frequently follows the address you typed. Where two fields disagree, the one the client actually reads is the one that wins, and it is rarely the one you edited.

Repair the profile or the certificate, deliberately

Inspect the peer certificate with approved tooling and list the SAN entries with their types before changing anything. That inspection needs no private key and no upload, and it settles the question in seconds. If the deployment intends one DNS identity, the certificate must carry it as a dNSName entry, and if the deployment intends an address, the certificate needs an iPAddress entry for exactly that address.

When the certificate is wrong, request a corrected one from the operator with the specific expected identifier. When the profile is wrong, fix the profile and leave the certificate alone. Disabling identity validation makes the error disappear and removes the check that the tunnel is talking to the peer you intended.

Document the expected identity per client platform, because a value one client derives automatically may need to be explicit on another.

Give the renewal request four facts

Write down the expected identifier and its type, the SAN entries the current certificate actually has, the client and version doing the check, and the exact error text. A renewal request built from those four lines gets the right certificate the first time, instead of another one with the same familiar filename.