Verification failed for URI

[Brent Putman]

On 8/2/18 5:39 PM, Cody Carmichael wrote:
> I know what's happening but I don't know why. I'm new to stuff like
> signing and encryption and the shibboleth docs don't explicitly say
> WHICH certificate you're supposed to point to with the certificateFile
> attribute of the SignatureValidation filter.

As Tom said, it would be the cert whose public key corresponds to the
private key used to sign the metadata.


> The cert.pem file is the SP's public key. The SAML request sent from
> the SP contains that same public key along with a DigestValue. But in
> the logs I have the following:
>
>     WARN [org.apache.xml.security.signature.Reference:791] -
>     Verification failed for URI "#_someLongString"
>     WARN [org.apache.xml.security.signature.Reference:792] - Expected
>     Digest: ABC123=
>     WARN [org.apache.xml.security.signature.Reference:793] - Actual
>     Digest: XYZ456=
>

You're obfuscating the values there, obviously, but if the expected vs
actual values are indeed different, then this is not indicating a cert
problem.  It really does mean that the signature was generated over
bytes that are different than what you are receiving.  So it really is
an invalid signature.

Since as Tom said, you seem to be using the "well-known location"
strategy, that means you're getting the metadata directly from the SP
dynamically. That's a bit unusual, but not really incorrect, if that is
what is intended here.  You'd have to followup with the SP to
troubleshoot this. Most likely something about the way they are storing
or hosting or publishing the metadata is causing changes to the metadata
document after signing, resulting in a signature validation failure even
if the validation key is correct (it may not be, you'd want to confirm
that as well). The addition or removal of even a single whitespace
character in the signed bytes of the document will result in signature
failure.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180802/df5e7c6d/attachment.html>