Best debug logging to enable

[Dan McLaughlin]

> > Question 2) Is it normal for the SAML 2 response to contain the CA's
> > public key that signed their signing/encryption certificate?
>
> It doesn't matter.

Hey Scott,

Thanks for the quick reply!  So if their SAML 2 response contains two
certs, the first is their CA cert, the second is their wildcard cert,
does this mean their metadata should also contain contain both?  If
so, what is the proper "use" to set for the CA cert in their metadata
or does it not matter?

Does it even make since to you that their SAML 2 response would
contain the CA's public key?  Why would that even matter since their
metadata only contains their IDP's public key, which is all I trust
anyways. Not only that, if the CA's public key was used by the SP to
encrypt anything and send it back they couldn't decrypt it anyways
since they don't have the CA's private key.

Is it possible that the SP could be pulling the CA's public key from
their SAML2 response and trying to use that to compare to the SP's
list of trusted metadata, and never even trying with the second key
from the reponse?  If that's what's happening then that could possibly
explain why it can't validate the signature since their metadata
doesn't contain the CA's public cert.  Unfortunately with the current
logging (DEBUG) it doesn't tell me what certificate from the SAML 2
response that the SP is comparing to the metadata, so I can't tell if
that's what's happening.  Is there a TRACE level logging I can enable
that might show that level of detail?

--

Thanks,

Dan McLaughlin
Technology Consortium, LLC
dmclaughlin at tech-consortium.com
mobile: 512.633.8086
http://www.tech-consortium.com

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

On Thu, Sep 6, 2018 at 11:29 AM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> On 9/6/18, 11:45 AM, "users on behalf of Dan McLaughlin" <users-bounces at shibboleth.net on behalf of dmclaughlin at tech-consortium.com> wrote:
>
> > What's the best logging to enable to debug the following error?
>
> That's probably a signature bug in their code, debugging that requires knowledge of XML Signature and using very low level options.
>
> The best case is that it's not a signing bug but they're using a different key to sign and it isn't showing up in the message or the metadata. That's unlikely.
>
> > Questions 1) Should wildcard certs coming from an IDP work for signing
> > and encryption? They worked before, so I'm assuming the answer is yes.
>
> The public key matters. Nothing else matters.
>
> > Question 2) Is it normal for the SAML 2 response to contain the CA's
> > public key that signed their signing/encryption certificate?
>
> It doesn't matter.
>
> > What else should we be looking at and is there any additional logging
> > we can enable to help get to the bottom of the issue?
>
> There's an old page in the V2 space about it.
> https://wiki.shibboleth.net/confluence/display/OpenSAML/OSTwoUserManSigErrors
>
> You need to move as fast as possible to some form of independent verification they have a bug to get it on their plate.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net