Credential failed name check.

Brent Putman putmanb at
Wed Aug 19 16:18:53 EDT 2015

On 8/19/15 10:47 AM, Cantor, Scott wrote:
> On 8/19/15, 10:34 AM, "users on behalf of Johan Åkerstrøm" <users-bounces at on behalf of Johan.Akerstrom at> wrote:
>> I'm getting this error.
>> 2015-08-19 16:12:47,308 - WARN [] - Signature verification failed.
>> 2015-08-19 16:12:47,312 - ERROR [] - Credential failed name check: [subjectName='OU=oiosaml-sp,CN=ht
>> tps://']
>> EntityID of the RP is: but the signing cert has the following subject: 'OU=oiosaml-sp,CN=' is this mismatch what is causing the error?
> I doubt it. There's very little context here, and there has to be far more in the log than just that. Name checking on a signature use case can only be relevant if it's already failed the explicit key check, so normally I would assume that the metadata here is wrong, and that's the more fundamental issue.

Agreed.  If you aren't intending to do PKIX trust, then the key(s) in
the SP's metadata is the problem.

> Assuming that was intentional, the PKIX engine would then do the name check, and I don't know exactly what it checks against, Brent would know. I thought we did automatic extraction of the CN of the subject,

Yes, by default we extract and evaluate: 1) the whole serialized
subject DN 2) the (first) CN from the subject 3) all DNS and URI
subject alt names

>  and the entityID ought to be an implicitly trusted key name, 

This looks like v3 and yes, it has done that from the 3.0.0.  (v2
didn't add until the most recent version, IIRC).

> so it seems like that should pass. But it shouldn't ever get that far anyway, and even if the name check worked, there would have to be a KeyAuthority extension in the metadata for path validation to pass.

Yes, and the PKIX signature trust engine does do the name check first,
so b/c of the error we can't actually infer whether there's any valid
KeyAuthority stuff in metadata for the cert path validation.

If you really are intending to do PKIX and you really think the name
check should be passing, then you can turn on DEBUG logging for at
least this class:

That will log the trusted names passed into it, as well as the results
of the various checks.  One of the passed trusted names will have to be
in the cert in one of the configured extraction locations.

Based on what you said above, the (implicitly trusted) entityID should
pass against the CN in the subject.  But as with another recent similar
thread, this is an exact string match, so since you are sanitizing your
log output, double-check that they are exactly the same, character for
character: no upper/lower case differences, trailing slash, etc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list