<div dir="ltr"><span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">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.</span><br style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial">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. </div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 2, 2018 at 7:09 PM, Brent Putman <span dir="ltr"><<a href="mailto:putmanb@georgetown.edu" target="_blank">putmanb@georgetown.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<p><br>
</p>
<br>
<div class="m_-3466493684067739551moz-cite-prefix">On 8/2/18 5:39 PM, Cody Carmichael
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>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. <br>
</div>
</div>
</blockquote>
<br></span>
As Tom said, it would be the cert whose public key corresponds to
the private key used to sign the metadata. <br><span class="">
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>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:</div>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">WARN
[org.apache.xml.security.<wbr>signature.Reference:791] -
Verification failed for URI "#_someLongString"<br>
WARN [org.apache.xml.security.<wbr>signature.Reference:792] -
Expected Digest: ABC123=<br>
WARN [org.apache.xml.security.<wbr>signature.Reference:793] -
Actual Digest: XYZ456=</blockquote>
</div>
</blockquote>
<br></span>
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.<br>
<br>
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.<br>
<br>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><p><br>
<br>
<img alt="" longdesc="https://ci3.googleusercontent.com/proxy/7vsBkuOy6ytSYqTS8t3aHsDYWhe-flv3eqHZBodSDhU8ffh8DNSWwR1Q2JIuYmRH_Tc4_Pt4QwhwCta1PkpgVb8Qqi-VHrs=s0-d-e1-ft#http://voalte.com/uploads/images/voalteemail3.png" src="http://voalte.com/uploads/images/voalteemail3.png" style="font-family:Times;font-size:medium;margin-left:14px;margin-right:14px;float:left;width:90px;height:75px;margin-top:10px;background-color:rgba(255,255,255,0.921569)"><span style="font-family:arial,helvetica,sans-serif"><span style="font-size:14px"><strong>Cody<span style="font-weight:bold;background-color:rgba(255,255,255,0.917969)"> </span>Carmichael<span style="background-color:rgba(255,255,255,0.917969);font-weight:bold"> </span></strong><br>Engineering Operations <span style="background-color:rgba(255,255,255,0.917969)"> | Voalte</span><br>
<span style="background-color:rgba(255,255,255,0.917969)">Office: 941-312-2830 | Ext </span></span></span><br>
<span style="font-family:arial,helvetica,sans-serif"><span style="font-size:14px;background-color:rgba(255,255,255,0.917969)">Email: </span></span><a href="mailto:ccarmichael@voalte.com" target="_blank">ccarmichael@voalte.com</a><br> </p><p><a href="http://www.voalte.com/klas-report-classifies-voalte-as-a-strategic-solution-provider-with-the-most-robust-interfacing/" target="_blank"></a><a href="http://www.voalte.com/klas-report-classifies-voalte-as-a-strategic-solution-provider-with-the-most-robust-interfacing/" target="_blank"></a><a href="http://www2.voalte.com/l/8232/2017-01-30/6k3skb" target="_blank"><img src="http://www2.voalte.com/l/8232/2017-01-30/6k3sjj/8232/170767/Voalte_Email_Signature.png"></a> </p></div></div></div>
</div>