Shibboleth SP 2.4.3 and ExplictKey TrustEngine - SOAP 8443 vs other

[Marc Thornton]

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.

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.
   - front channel for both idp's are served by https://..:443 (2 different
context roots)
   - back channel for idp #1 is served by https://...:8443
   - back channel for idp #2 is served by https://...:8445

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.

We are using artifact resolution to transport our assertions, hence
SOAP/TLS validation is part of the authentication process.

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.

The section of logs at debug level is below:

2011-12-01 10:47:59 DEBUG XMLTooling.SOAPTransport.CURL [9]: sending SOAP
message to https://<fqdn>:9443/idp/profile/SAML2/SOAP/ArtifactResolution
2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: About to connect()
to <fqdn> port 9443
2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]:   Trying <ipaddress>...
2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: connected
2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: Connected to
wls1032a.istc.agr.gc.ca (ipaddress) port 9443
2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: SSLv3, TLS handshake,
Client hello (1):
2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: SSLv3, TLS handshake,
Server hello (2):
2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: SSLv3, TLS handshake,
CERT (11):
2011-12-01 10:47:59 DEBUG XMLTooling.libcurl [9]: ^K
2011-12-01 10:47:59 DEBUG XMLTooling.SOAPTransport.CURL [9]: invoking
custom X.509 verify callback
2011-12-01 10:47:59 DEBUG XMLTooling.TrustEngine.ExplicitKey [9]:
attempting to match credentials from peer with end-entity certificate
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

Version of curl is curl-7.15.5-2.1.el5_3.5

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)

Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20111201/407bbf5b/attachment.html