I am having an odd issue and figured I would post it here, since I can't locate why this would be an issue in the Shibboleth SP (and supporting library) code.<div><br></div><div>Due to limitations on development environment resources, I have two Shibboleth IDP's hosted on a single RHEL 5 64-bit server. Apache 2.2 provides both front & back channel connectivity via self-signed certs.</div>
<div> - front channel for both idp's are served by https://..:443 (2 different context roots)</div><div> - back channel for idp #1 is served by https://...:8443</div><div> - back channel for idp #2 is served by https://...:8445</div>
<div><br>
</div><div>We have recently upgraded to Shibboleth SP 2.4.3 from Shibboleth SP 2.3.1. Supporting libraries had been previously upgraded to 2.4.3 "levels" to resolve the XML signature vulnerability, hence only the Shibboleth SP software has been upgraded in this pass.</div>
<div><br></div><div>We are using artifact resolution to transport our assertions, hence SOAP/TLS validation is part of the authentication process.</div><div><br></div><div>Since upgrading to Shibboleth SP 2.4.3, the ExplicitKey TrustEngine seems to work only for validating SOAP/TLS over port 8443.. attempts to validate against the same web server certificate over 8445 or 9443 fail for no apparent reason. I've confirmed that ExplicitKey TrustEngine gave us a successful match over non-8443 ports on the previous release.</div>
<div><br></div><div>The section of logs at debug level is below:</div><div><br></div><div><div>2011-12-01 10:47:59 DEBUG XMLTooling.SOAPTransport.CURL [9]: sending SOAP message to https://<fqdn>:9443/idp/profile/SAML2/SOAP/ArtifactResolution</div>
<div>2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: About to connect() to <fqdn> port 9443</div><div>2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: Trying <ipaddress>...</div><div>2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: connected</div>
<div>2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: Connected to <a href="http://wls1032a.istc.agr.gc.ca">wls1032a.istc.agr.gc.ca</a> (ipaddress) port 9443</div><div>2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: SSLv3, TLS handshake, Client hello (1):</div>
<div>2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: SSLv3, TLS handshake, Server hello (2):</div><div>2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: SSLv3, TLS handshake, CERT (11):</div><div>2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: ^K</div>
</div><div>2011-12-01 10:47:59 DEBUG XMLTooling.SOAPTransport.CURL [9]: invoking custom X.509 verify callback</div><div><div>2011-12-01 10:47:59 DEBUG XMLTooling.TrustEngine.ExplicitKey [9]: attempting to match credentials from peer with end-entity certificate</div>
<div>2011-12-01 10:47:59 DEBUG XMLTooling.TrustEngine.ExplicitKey [9]: no keys within this peer's key information matched the given end-entity certificate</div></div><div><br></div><div>Version of curl is curl-7.15.5-2.1.el5_3.5</div>
<div><br></div><div>As mentioned, I've dug into the source for the Shibboleth SP and other libraries and can't locate any instances where 8443 would be a "requirement" or would change the behaviour. I find this odd, to say the least but hope someone might have a clue as to what's going on (or if, oddly enough, I've done something really wrong)</div>
<div><br></div><div>Marc</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>