Verification failed for URI

Tom Scavo trscavo at
Thu Aug 2 18:28:31 EDT 2018

On Thu, Aug 2, 2018 at 5:39 PM, Cody Carmichael <ccarmichael at> wrote:
> Here is my Metadata provider configuration:
>> <MetadataProvider id="HTTPMetadataCRC"
>>                   xsi:type="DynamicHTTPMetadataProvider">
>>         <MetadataFilter xsi:type="SignatureValidation"
>> requireSignedRoot="true"
>>                 certificateFile="%{idp.home}/credentials/cert.pem"/>
>> </MetadataProvider>

This metadata provider has no child element (apart from the metadata
filter of course). Is that intentional? (I doubt it.)

>From the wiki:

If you forget to configure a child element, the provider will default
to the well-known location strategy. This constrains the entityID to
be an URL (not an URN) but the provider does not check the URL scheme.
If the scheme on the entityID is "http:", the metadata exchange will
be vulnerable to a man-in-the-middle attack. For this reason, the
well-known location strategy should be avoided in most cases.

> 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.

The public key in SP metadata has nothing to do with the signature on
the SP metadata file.

> So, what specific cert file is the certificateFile attribute supposed to be
> pointing to?

It is the public key corresponding to the private key that signed the metadata.

You need to step back for a moment. The IdP rarely obtains SP metadata
directly from the SP, at least not dynamically.


More information about the users mailing list