<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 3/10/17 4:07 PM, Cantor, Scott
      wrote:<br>
    </div>
    <br>
    <blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE11BFD4D07@CIO-TNC-D2MBX02.osuad.osu.edu"
      type="cite">
      <pre wrap="">

The unusual aspect of it falling into the name checking step and failing there suggests this has to be a POST binding request, not a redirect. For the certificate to be seen, it must be getting it via the message, so that means POST.
</pre>
    </blockquote>
    <br>
    Good point.<br>
    <br>
    <blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE11BFD4D07@CIO-TNC-D2MBX02.osuad.osu.edu"
      type="cite">
      <pre wrap="">
The signature must be validating with the key in the message, but it must not match the SP's metadata, </pre>
    </blockquote>
    <br>
    Probably. I think there's 2 possibilities from the (possibly
    incomplete) info of the 2 log lines: 1) as you say, the
    message-level KeyInfo passed crypto verification, but failed trust
    eval, and the ExplicitKey engine falls back to validating with each
    cred from metadata.  So the Santuario "Signature verification
    failed" is just coming from the last metadata cred that was tried.
    (And all metadata creds were invalid).  Or  2)  The message KeyInfo
    failed crypto verification, and that's the source of the Santuario
    message.<br>
    <br>
    <blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE11BFD4D07@CIO-TNC-D2MBX02.osuad.osu.edu"
      type="cite">
      <pre wrap="">at which point it starts trying to path validate and then tries to validate the name in the certificate. That's all just noise, nobody's using PKIX and it's simply not able to match the key against the metadata, so that has to be the real problem.
</pre>
    </blockquote>
    <br>
    Yes, it's falling through to PKIX and failing the name check.  Since
    it wouldn't have even gotten to the name check if the message
    KeyInfo failed crypto verification, then I think that eliminates #2
    above.  So it must be #1, which is due to bad metadata.<br>
    <br>
    But it's hard trying to reconstruct this based on 2 log lines, which
    are possibly incomplete, and no knowledge of the config or
    metadata.  It would be more clear if the OP could provide a DEBUG
    log extract of the whole signature validation sequence.<br>
    <br>
  </body>
</html>