<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 8/2/18 5:39 PM, Cody Carmichael
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAL9ddzLrJedJOKnU_EKWzLiVd=Q0YZwfzrnayKwn+=BbfWXehw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<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>
As Tom said, it would be the cert whose public key corresponds to
the private key used to sign the metadata. <br>
<br>
<br>
<blockquote type="cite"
cite="mid:CAL9ddzLrJedJOKnU_EKWzLiVd=Q0YZwfzrnayKwn+=BbfWXehw@mail.gmail.com">
<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.signature.Reference:791] -
Verification failed for URI "#_someLongString"<br>
WARN [org.apache.xml.security.signature.Reference:792] -
Expected Digest: ABC123=<br>
WARN [org.apache.xml.security.signature.Reference:793] -
Actual Digest: XYZ456=</blockquote>
</div>
</blockquote>
<br>
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>
</body>
</html>