<div dir="ltr">Ah, you were correct that I needed to look earlier in the logs. <div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[org.apache.xml.security.signature.Reference:791] - Verification failed for URI "#_f82d91b40d8850701548612d14cedb7b"<br>[org.apache.xml.security.signature.Reference:792] - Expected Digest: Igunx6qgopGS6lUqRjopyPq9wLZN51legZzLMQb0Q98=<br>[org.apache.xml.security.signature.Reference:793] - Actual Digest: N/rKwh55tO5Ap5n9FIHEMwgmRn/iUE/TiuGiLGDan/0=</blockquote><div><br></div><div>The dev has checked the code on their side and found no issues in the signature. Does it matter that the cert.pem that my metadata-provider is pointing to is a standard public cert that contains the 'BEGIN CERTIFICATE/END CERTIFICATE' strings? The key and cert were created per the "Creating a SAML key and Certificate" section of the docs except the signature algorithm is sha256WithRSAEncryption instead of the sha1WithRSAEncryption that appears in the example. Exactly what part of the metadata needs to be hashed to create the digest value that is added in the signed info? </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 6, 2018 at 4:15 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><span class="gmail-">
    <p><br>
    </p>
    <br>
    <div class="gmail-m_-5952622492435834362moz-cite-prefix">On 8/6/18 3:27 PM, Cody Carmichael
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div class="gmail_extra">Yes I did post last week about the logs
          showing different values for the expected and actual digest
          values. The logs are no longer showing messages about that.
          Right now the logs spit out the decoded SAML message that
          contains stuff for the AuthnRequest like the DigestMethod,
          DigestValue, SignatureValue, KeyInfo, etc... <br>
        </div>
      </div>
    </blockquote>
    <br></span>
    Errors about the signature validation would occur well before that. 
    Since this is the Filesystem- provider, errors there would occur at
    IdP startup and/or at metadata refresh time.  I'd wager a hefty sum
    that if you restart your IdP, and then look the logs since that
    startup (without even attempting any SP login activity) you will see
    errors there from the SignatureValidation filter and the components
    it calls.<span class="gmail-"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">There is also this message at the end
          of the log:</div>
        <div class="gmail_extra"><br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Profile
          Action SelectProfileConfiguration: Profile <a href="http://shibboleth.net/ns/profiles/saml2/sso/browser" target="_blank">http://shibboleth.net/ns/<wbr>profiles/saml2/sso/browser</a>
          is not available for RP configuration
          shibboleth.<wbr>UnverifiedRelyingParty (RPID <a href="https://mySP.net/rest/v2/sso/message/shibboleth/metadata" target="_blank">https://mySP.net/rest/v2/sso/<wbr>message/shibboleth/metadata</a>)</blockquote>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">But I figured that was because it's
          calling my SP unverified because it's not finding the
          metadata, and it's not finding the metadata for reasons I
          haven't figured out. </div>
      </div>
    </blockquote>
    <br></span>
    Correct, exactly.  In the IdP "unverified" means "no metadata" for
    that entity.<span class="gmail-"><br>
    <br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">If the signature validation check is
          still failing, the logs are not giving any indication of it. </div>
        <br>
      </div>
    </blockquote>
    <br></span>
    Look earlier in the logs.  The errors with the Filesystem- provider
    will happen at IdP start time, not when you are attempting to log in
    to your SP.  (The latter would be true as you were doing before with
    the dynamic HTTP provider, since there it's going to resolve the
    metadata at runtime when it first needs to be looked up.)<span class="gmail-HOEnZb"><font color="#888888"><br>
    <br>
    --Brent</font></span></div></blockquote></div>
</div></div>