Thanks for talking me through this, Scott. It was, unfortunately (fortunately?) a mis-configuration in the Apache server. A typo in another VirtualHost that I'd recently added meant a different/wrong certificate was being presented. Your suggestion to double-check which cert is returned using a standard browser is what led me to the culprit.<div>
<br></div><div>I agree that a bit more debug information related to the cert in the XMLTooling handling of the X509 callback might be a nice addition, but obviously, proper management of configuration is what can make or break functionality pretty easily.</div>
<div><br></div><div>Thanks for the information on how the configuration is handled. Most of our "risk" is in the ApplicationDefaults and ApplicationOverride as these are the most often configured items by our internal clients (and hence, all possible configuration not as easily tested by us). We will definitely keep in mind how other libraries impact the interpretation of configuration files if we need to make a reasonably quick release available again for issues or vulnerabilties.<br>
<div><br></div><div><div>I appreciate the quick turnaround on this... now I can get back to what i was really working on!</div><div><br></div><div>-- Marc</div><div><br><div class="gmail_quote">On Thu, Dec 1, 2011 at 12:57 PM, 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 12:40 PM, "Marc Thornton" <<a href="mailto:joey.granville@gmail.com">joey.granville@gmail.com</a>> wrote:<br>
><br>
>Yes, we do build our own SP from source, unchanged except for packaging &<br>
>"standardized" configuration files that we provide to our internal<br>
>clients for installation consistency. This approach also allowed us, as<br>
>you surmised, to drop in the OpenSAML digital signature vulnerability fix<br>
>in a shorter timeframe, while retaining the same source release for the<br>
>Shibboleth SP (and hence, assured SP configuration compatibility).<br>
<br>
</div>Just FYI, the SP already assures this. In fact, much of the internal<br>
configuration content found in various elements of the files is for<br>
plugins provided by the lower libraries. It's as likely to get a<br>
regression in those as with the SP itself.<br>
<div class="im"><br>
>That is what went through my head as I investigated this... although it<br>
>also occurs to me that the SP could have changed how it initialized or<br>
>made calls to these supporting libraries in between releases.<br>
<br>
</div>It's possible, yes, but not likely. I can't think of any obvious way it<br>
would manifest like this. I could absolutely understand a regression or<br>
problem in the libraries themselves, but that would show up with the old<br>
SP using them.<br>
<div class="im"><br>
>Unfortunately, it doesn't look like it logs any certificate details until<br>
>the (per the log) X509 Callback completes successfully. Since it fails<br>
>on the callback, no further information on the certificate is logged.<br>
<br>
</div>Must be something libcurl does, I guess, I never noticed. That's kind of a<br>
hassle. If you're building at least some of it from source, I guess an<br>
obvious possibility is to dump/log the certificate the callback is<br>
evaluating. I can certainly look at adding that and/or point you to the<br>
relevant spot, but it's not in the SP obviously.<br>
<div class="im"><br>
>That is pretty much what i've been doing...<br>
> - Update SP's copy of idp-metadata to use 8445 for<br>
>AssertionConsumerService<br>
> - Update IDP's copy of idp-metadata to use 8445 for<br>
>AssertionConsumerService<br>
<br>
</div>You mean the ArtifactResolutionService?<br>
<div class="im"><br>
> - Update apache configuration Listen, VirtualHost and ServerName<br>
>directives to identify 8445... restart it all... authentication fails at<br>
>SAML Artifact lookup...<br>
><br>
>Do the same with 8443 or 9443, identical self-signed web cert and key...<br>
>success.<br>
<br>
</div>That's mystifying. I assume you did something to connect directly to that<br>
port and just make absolutely certain Apache is serving up that<br>
certificate? Browser or openssl s_client.<br>
<div class="im"><br>
>Note that the certificate for the self-signed web server cert itself is<br>
>not included in the IDP metadata, but that seems to be irrelevant as the<br>
>ExplicitKeyTrustEngine only compares public keys components (modulus,<br>
>exponent) to determine a match, never the certificate details.<br>
<br>
</div>That's true, yes. I wouldn't say it's a good idea to go that route since<br>
basically no other software but ours does that (only we implement the<br>
profile in question where that's codified). But for sanity checking sake,<br>
did you try actually putting that certificate into the metadata?<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div></div></div>