Verification failed for URI

[Cody Carmichael]

The SP in this case is a product under development by the company I work
for. I've been working with the SP's dev for several days on this and
unfortunately it's very time sensitive. What would be the more 'usual' way
to get metadata from the SP? FileBackedHttp? I'm new to most of the
concepts involved with shibboleth so I don't have a concept of the typical
way to do things.

What would make the signature invalid? The dev generated the public and
private keys and I have a copy of the public key which is the cert.pem
that's being pointed to.


On Thu, Aug 2, 2018 at 7:09 PM, Brent Putman <putmanb at georgetown.edu> wrote:

>
>
> 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.
>
>


-- 



*Cody Carmichael *
Engineering Operations  | Voalte
Office: 941-312-2830 | Ext
Email: ccarmichael at voalte.com


<http://www.voalte.com/klas-report-classifies-voalte-as-a-strategic-solution-provider-with-the-most-robust-interfacing/>
<http://www.voalte.com/klas-report-classifies-voalte-as-a-strategic-solution-provider-with-the-most-robust-interfacing/>
<http://www2.voalte.com/l/8232/2017-01-30/6k3skb>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180802/d124ae55/attachment.html>