our SP seems to connect using the wrong IP address

[Maassen, Helma]

hi Scott,

I do not want to waste your time...!

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.
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.

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?
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.

Best regards, and very much thanks for your time.

Helma Maassen
Atos Nederland B.V.
Technology Services Zuid
High Tech Campus 52
5656 AG Eindhoven

On 11/29/2012 03:47 PM, Cantor, Scott wrote:


On 11/29/12 3:15 AM, "Maassen, Helma" <Helma.Maassen at atos.net><mailto:Helma.Maassen at atos.net> wrote:



I am trying to find out where Shibboleth decides to take the eth0:0
interface as opposed to eth0 interface.
I did focus too much on libcurl for a solution, but maybe it lies in the
Apache virtualhost configuration, where only the loket.xxxxx.nl
configuration has Shibboleth configured, so I expected that the
connection would be initiated from eth0/loket.xxxxx.nl, but it is not :-(



I still don't understand which end you're claiming is the problem. The
client end can't possibly have anything to do with Apache, but I can't
think why the client's choice of interface would matter, but if you're
talking about the server, it certainly is nothing to do with libcurl. So,
lost.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>







Dit bericht is vertrouwelijk en kan geheime informatie bevatten enkel bestemd voor de geadresseerde. Indien dit bericht niet voor u is bestemd, verzoeken wij u dit onmiddellijk aan ons te melden en het bericht te vernietigen. Aangezien de integriteit van het bericht niet veilig gesteld is middels verzending via internet, kan Atos Nederland B.V. niet aansprakelijk worden gehouden voor de inhoud daarvan. Hoewel wij ons inspannen een virusvrij netwerk te hanteren, geven wij geen enkele garantie dat dit bericht virusvrij is, noch aanvaarden wij enige aansprakelijkheid voor de mogelijke aanwezigheid van een virus in dit bericht. Op al onze rechtsverhoudingen, aanbiedingen en overeenkomsten waaronder Atos Nederland B.V. goederen en/of diensten levert zijn met uitsluiting van alle andere voorwaarden de Leveringsvoorwaarden van Atos Nederland B.V. van toepassing. Deze worden u op aanvraag direct kosteloos toegezonden.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Nederland B.V. group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. On all offers and agreements under which Atos Nederland B.V. supplies goods and/or services of whatever nature, the Terms of Delivery from Atos Nederland B.V. exclusively apply. The Terms of Delivery shall be promptly submitted to you on your request.

Atos Nederland B.V. / Utrecht
KvK Utrecht 30132762