Signature trust could not be established via PKIX validation of signing credential

[Schumacher, Adam J.]

> I don't think that could be the case unless you've disabled the trust engine at
> the IdP that supports the direct key evaluation. It's falling into PKIX which
> means it either didn't try the other, or it didn't work.
> 
I've not modified any trust engines from the default in relying-party.xml.  If it didn't work, what log would show that?  This is what I have currently in relying-party.xml:

<security:TrustEngine id="shibboleth.SignatureTrustEngine" xsi:type="security:SignatureChaining">
        <security:TrustEngine id="shibboleth.SignatureMetadataExplicitKeyTrustEngine" xsi:type="security:MetadataExplicitKeySignature"
                              metadataProviderRef="ShibbolethMetadata" />
        <security:TrustEngine id="shibboleth.SignatureMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXSignature"
                              metadataProviderRef="ShibbolethMetadata" />
    </security:TrustEngine>

    <security:TrustEngine id="shibboleth.CredentialTrustEngine" xsi:type="security:Chaining">
        <security:TrustEngine id="shibboleth.CredentialMetadataExplictKeyTrustEngine" xsi:type="security:MetadataExplicitKey"
                              metadataProviderRef="ShibbolethMetadata" />
        <security:TrustEngine id="shibboleth.CredentialMetadataPKIXTrustEngine" xsi:type="security:MetadataPKIXX509Credential"
                              metadataProviderRef="ShibbolethMetadata" />
    </security:TrustEngine>

> The content of the certificate aside from the key is totally irrelevant unless
> the key doesn't match the metadata or it isn't checking that case.
> 
Okay, that is good to know.  Since the entire certificate including the key matches in both the AuthnRequest and the metadata, it must not be checking for some reason.  Unless there is something wrong/missing in the configuration above, what else would cause that?  I checked the metadata sources for duplicate entityIDs (sanity check as you'd suggested) and there were no duplicates.

::Adam