Minor update:<div><br></div><div><div>In further testing, I found an issue with my Apache configuration when I initially tested 9443... with everything properly configured, 9443 does work... 8445 (our previous configuration) continues to give failures. Other comments inline.</div>
<div><br></div><br><div class="gmail_quote">On Thu, Dec 1, 2011 at 11:38 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 12/1/11 11:05 AM, "Marc Thornton" <<a href="mailto:joey.granville@gmail.com">joey.granville@gmail.com</a>> wrote:<br>
<br>
>We have recently upgraded to Shibboleth SP 2.4.3 from Shibboleth SP<br>
>2.3.1. Supporting libraries had been previously upgraded to 2.4.3<br>
>"levels" to resolve the XML signature vulnerability, hence only the<br>
>Shibboleth SP software has been upgraded in this pass.<br>
<br>
</div>Unless you were building from source, you couldn't use the newer libraries<br>
with a 2.3.1 SP. So I assume you did that, but just making the point in<br>
case there's something off about your build, and because that leaves open<br>
to question what the build process is.<br></blockquote><div>Yes, we do build our own SP from source, unchanged except for packaging & "standardized" configuration files that we provide to our internal clients for installation consistency. This approach also allowed us, as you surmised, to drop in the OpenSAML digital signature vulnerability fix in a shorter timeframe, while retaining the same source release for the Shibboleth SP (and hence, assured SP configuration compatibility).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
>We are using artifact resolution to transport our assertions, hence<br>
>SOAP/TLS validation is part of the authentication process.<br>
<br>
</div>Since it comes up from time to time, any reason for that?<br></blockquote><div>Our client base of Service Providers is completely internal to our network. We decided early on that the increased security of providing assertion details over SOAP was worth the overhead of firewall rules/connectivity between the various systems on the same network. We would never have considered it had we been serving external Service Providers.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
>Since upgrading to Shibboleth SP 2.4.3, the ExplicitKey TrustEngine seems<br>
>to work only for validating SOAP/TLS over port 8443.. attempts to<br>
>validate against the same web server certificate over 8445 or 9443 fail<br>
>for no apparent reason. I've confirmed that ExplicitKey TrustEngine gave<br>
>us a successful match over non-8443 ports on the previous release.<br>
<br>
</div>The SP on top has nothing to do with this step. The TLS is OpenSSL, the<br>
HTTPS is libcurl, the cert evaluation (the trust engine) is xmltooling,<br>
and the metadata is opensaml. So if you had some particular version of<br>
those working, and then upgraded only the SP on top, none of that would<br>
change.<br></blockquote><div>That is what went through my head as I investigated this... although it also occurs to me that the SP could have changed how it initialized or made calls to these supporting libraries in between releases.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
>The section of logs at debug level is below:<br>
<br>
</div>I don't see any sign of session resumption, so all I can say is, whatever<br>
cert it's getting back is not what's in the metadata.<br>
<br>
I thought libcurl on DEBUG would log the cert from the handshake though.<br>
It's not there?<br></blockquote><div>Unfortunately, it doesn't look like it logs any certificate details until the (per the log) X509 Callback completes successfully. Since it fails on the callback, no further information on the certificate is logged.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Are you using the official packages at this point?</div></blockquote><div>Yes, all packages other than the Shibboleth SP are official packages. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I don't know if it's possible to do it, but I would also try swapping<br>
which endpoint is which on the IdP end, and see if it consistently fails<br>
with that port, or instead with the certificate.<br></blockquote><div>That is pretty much what i've been doing... </div><div> - Update SP's copy of idp-metadata to use 8445 for AssertionConsumerService</div><div>
- Update IDP's copy of idp-metadata to use 8445 for AssertionConsumerService</div><div> - Update apache configuration Listen, VirtualHost and ServerName directives to identify 8445... restart it all... authentication fails at SAML Artifact lookup...</div>
<div><br></div><div>Do the same with 8443 or 9443, identical self-signed web cert and key... success.</div><div><br></div><div>Note that the certificate for the self-signed web server cert itself is not included in the IDP metadata, but that seems to be irrelevant as the ExplicitKeyTrustEngine only compares public keys components (modulus, exponent) to determine a match, never the certificate details. Since the cert in the IDP metadata and the web server cert are generated based on the same private key, they share the same public key as well. (I think I gained a few more gray hairs until I figured that particular piece of information out)</div>
<div><br></div><div>-- Marc</div></div></div>