
<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <br>

    <div class="moz-cite-prefix">On 2/1/15 8:21 PM, Andrew

      Devenish-Meares wrote:<br>

    </div>

    <blockquote cite="mid:54CED11B.1080605@une.edu.au" type="cite">

      <pre wrap="">


Thanks for that.  I've installed that and got it working, in terms of 

presenting the certificate chain. </pre>

    </blockquote>

    <br>

    Ok, great.  Glad to hear that the extension works as expected.<br>

    <br>

    <br>

    <blockquote cite="mid:54CED11B.1080605@une.edu.au" type="cite">

      <pre wrap=""> The vendor's server still does not 

accept this, however.  (And yes, I can verify the chain with OpenSSL 

*grin*).

</pre>

    </blockquote>

    <br>

    <br>

    Hmm.  Well, assuming you are including all the intermediate certs

    back to (but not including) the root CA, then the obvious suspicion

    is that they don't have the root CA effectively trusted like they

    claim.  That would be on them.  Or if they are a Shibboleth SP, then

    on whomever is managing the metadata they're using - the root CA

    would need to be enumerated as a shibmd:KeyAuthority.<br>

    <br>

    If this is a Shibboleth SP, another failure could be a mismatch in

    the KeyName(s) they have in the metadata for your IdP vis-a-vis your

    entity cert.<br>

    <br>

    From a trust perspective that's all I can think of at the moment. 

    There are of course other general reasons why the Signature

    validation could fail (e.g. response bytes changing after signing

    and before verification, broken signature impl on their side, etc),

    or the whole Response being rejected (e.g. timestamps invalid, being

    delivered to the wrong endpoint, etc).  I'd verify all the trust

    stuff before I went there, though.  If they are a Shibboleth SP,

    then most of those types of things can be ruled out.<br>

  </body>

</html>