our SP seems to connect using the wrong IP address
cantor.2 at osu.edu
Thu Nov 29 11:32:46 EST 2012
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
>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
>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
>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.
More information about the users