Shibboleth SP 2.4.3 and ExplictKey TrustEngine - SOAP 8443 vs other

[Marc Thornton]

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.

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.

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.

I appreciate the quick turnaround on this... now I can get back to what i
was really working on!

-- Marc

On Thu, Dec 1, 2011 at 12:57 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 12/1/11 12:40 PM, "Marc Thornton" <joey.granville at gmail.com> wrote:
> >
> >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).
>
> Just FYI, the SP already assures this. In fact, much of the internal
> configuration content found in various elements of the files is for
> plugins provided by the lower libraries. It's as likely to get a
> regression in those as with the SP itself.
>
> >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.
>
> It's possible, yes, but not likely. I can't think of any obvious way it
> would manifest like this. I could absolutely understand a regression or
> problem in the libraries themselves, but that would show up with the old
> SP using them.
>
> >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.
>
> Must be something libcurl does, I guess, I never noticed. That's kind of a
> hassle. If you're building at least some of it from source, I guess an
> obvious possibility is to dump/log the certificate the callback is
> evaluating. I can certainly look at adding that and/or point you to the
> relevant spot, but it's not in the SP obviously.
>
> >That is pretty much what i've been doing...
> >   - Update SP's copy of idp-metadata to use 8445 for
> >AssertionConsumerService
> >   - Update IDP's copy of idp-metadata to use 8445 for
> >AssertionConsumerService
>
> You mean the ArtifactResolutionService?
>
> >   - Update apache configuration Listen, VirtualHost and ServerName
> >directives to identify 8445... restart it all... authentication fails at
> >SAML Artifact lookup...
> >
> >Do the same with 8443 or 9443, identical self-signed web cert and key...
> >success.
>
> That's mystifying. I assume you did something to connect directly to that
> port and just make absolutely certain Apache is serving up that
> certificate? Browser or openssl s_client.
>
> >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.
>
> That's true, yes. I wouldn't say it's a good idea to go that route since
> basically no other software but ours does that (only we implement the
> profile in question where that's codified). But for sanity checking sake,
> did you try actually putting that certificate into the metadata?
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20111201/4a4252e3/attachment.html