Hi Michael,
If both connections in the config match, which one is chosen? First one? Most specific (where OU matches)?
They are ordered based on how well the remote and/or the local identities match (basically depends on the type and number of wildcards in the configured identity, although, only DNs support more than one wildcard). If they match equally well, the first one.
For instance, in the ikev2/wildcard scenario, the identity "C=CH, O=strongSwan Project, OU=Research, CN=*" of the first config always matches the client's identity "C=CH, O=strongSwan Project, OU=Research, CN=ca...@strongswan.org" better than id = %any (the default) of the second config, so the order doesn't matter there. Same would be the case if the identity in the second config was e.g. "C=CH, O=strongSwan Project, OU=*, CN=*" as the first config has the better matching identity configured.
There is also the charon.rdn_matching setting that's relevant here. With the default of `strict`, the order as well as the number and type of RDNs have to match exactly. With `reordered` the order is ignored, the number and type still have to match, so e.g. a certificate that has the RDNs in reverse order, such as "CN=ca...@strongswan.org, OU=Research, O=strongSwan Project, C=CH", would match the configured DN above. With `relaxed`, the number of RDNs doesn't have to match and all RDNs that are not configured are implicitly treated like wildcards. So e.g. id = "OU=Research" would match the above client identity with three wildcards. In that regard it would match equally well as "C=*, O=*, OU=Research, CN=*". However, it would also match an identity like "OU=Research, CN=ca...@strongswan.org", which the latter wouldn't, even in relaxed mode, because two of the configured RDNs are missing.
Note that it's not possible to match RDNs partially. And for FQDN and email addresses, e.g. to match against SANs, only the beginning can be ignored (e.g. id = "*@research.strongswan.org" or id = "*.strongswan.org").
Regards, Tobias
