our SP seems to connect using the wrong IP address

[Cantor, Scott]

On 11/29/12 11:28 AM, "Maassen, Helma" <Helma.Maassen at atos.net> wrote:
>
>We're hosting an SP on a multiinterfaced linux machine;
>url                IP                 certificate        interface
>dloket.xxxxx.nl    xxx.xxx.xxx.208    dloket.xxxxx.nl    eth0
>dmid.xxxxx.nl      xxx.xxx.xxx.209    dmid.xxxxx.nl      eth0:0

Ok.

>It seems that the SOAP connection between our SP and (not our) IdP for
>resolving the artifact, is set up by our SP, but using the dmid.xxxxx.nl
>address/interface. That what is reported by the people from the IdP.

Ok. So that has nothing to do with Apache of any stripe, obviously.

>The public certificate that we shared with the IdP is for
>dloket.xxxxx.nl, and not dmid.xxxxx.nl, so when they "check the
>certificate", the CN does not match the url.

If it's a Shibboleth IdP, what matters is that the public key you gave
them matches. The content of the certificate is totally irrelevant, nor
should you be using a TLS server cert from your web server in any SAML
communication to an IdP. That should be a separate credential.

If it's not a Shibboleth IdP, then all bets are off, but this has nothing
to do with URLs. Your client cert has nothing to do with your web server's
name(s).

>Thanks to your earlier tip on that CURLOPT_INTERFACE, we now can make a
>connection using the dloket.xxxxx.nl address, but is that the only way to
>convince Shibboleth to use that interface to setup the connection?

Yes, but that isn't your issue. The interface it's using has *nothing* to
do with the certificate it's using. The SP decides that, not your web
server.

>We need to configure a server park of about 90 servers (with diff.
>interfaces), so I would like to make sure before I have to configure them
>all over again.

Don't. It's not the issue.

-- Scott