strongSwan

Tobias Brunner wrote:

You should really not use this patch. Why do you think you need it?

Quite a strange situations, but we have devices (clients) that use a certificate with a DN subject "X" however later send the value "Y" in IDr of IKE AUTH.

The above works with another Security Gateway that we have (which I know is problematic), but we need to do some tests with these devices connected to strongSwan, now since we cannot change the certificate in the Devices and we cannot set leftid on strongSwan to both "X" and "Y", strongSwan fails to find the matching peer configuration.

Unfortunately, these are also devices configured to not use EAP-Only...

Any ideas ?

Quite a strange situations, but we have devices (clients) that use a certificate with a DN subject "X" however later send the value "Y" in IDr of IKE AUTH.

I assume you mean IDi (IDr is the responder identity) and I assume further that "Y" is not contained as subjectAltName in these client certificates. If that's the case, this is, in fact, problematic. The config lookup will be done using "Y" as that's what's submitted, but if you configure that and this identity is not contained in the certificate the authentication will fail afterwards. The patches in the cert-id-binding-option branch would allow this, but they basically allow anybody with an accepted certificate to authenticate with an arbitrary accepted identity. I rebased the branch to the current master (only compile-tested), but you should really fix your certificates/configs instead.

Tobias Brunner wrote:

Quite a strange situations, but we have devices (clients) that use a certificate with a DN subject "X" however later send the value "Y" in IDr of IKE AUTH.

I assume you mean IDi (IDr is the responder identity) and I assume further that "Y" is not contained as subjectAltName in these client certificates. If that's the case, this is, in fact, problematic. The config lookup will be done using "Y" as that's what's submitted, but if you configure that and this identity is not contained in the certificate the authentication will fail afterwards. The patches in the cert-id-binding-option branch would allow this, but they basically allow anybody with an accepted certificate to authenticate with an arbitrary accepted identity. I rebased the branch to the current master (only compile-tested), but you should really fix your certificates/configs instead.

Thank you Tobias, will give it a go.

We are working on fixing the certificates... but as you probably know, it's a painful process (can't wait for all the devices to switch to EAP-Only :))