Credential failed name check.

Johan Åkerstrøm Johan.Akerstrom at
Thu Aug 20 08:39:27 EDT 2015

Update from log:

2015-08-20 14:35:05,032 - WARN [] - Signature verification failed.
2015-08-20 14:35:05,039 - DEBUG [] - Checking trusted names against credential: [subjectName='OU=oio
2015-08-20 14:35:05,040 - DEBUG [] - Trusted names being evaluated are: [https://intra.brottsforebyg]
2015-08-20 14:35:05,040 - DEBUG [] - Processing subject alt names
2015-08-20 14:35:05,085 - DEBUG [] - Extracted subject alt names from certificate: []
2015-08-20 14:35:05,086 - DEBUG [] - Processing subject DN common name
2015-08-20 14:35:05,102 - DEBUG [] - Extracted common name from certificate: https://saml.intra.brot
2015-08-20 14:35:05,102 - DEBUG [] - Processing subject DN
2015-08-20 14:35:05,103 - DEBUG [] - Extracted X500Principal from certificate: OU=oiosaml-sp,CN=http
2015-08-20 14:35:05,103 - DEBUG [] - Trusted name was not a DN or could not be parsed: https://intra
2015-08-20 14:35:05,104 - ERROR [] - Credential failed name check: [subjectName='OU=oiosaml-sp,CN=ht

Best regards
Johan Åkerstrøm
-----Original Message-----
From: users [mailto:users-bounces at] On Behalf Of Johan Åkerstrøm
Sent: Thursday, August 20, 2015 2:32 PM
To: Shib Users <users at>
Subject: RE: Credential failed name check.

Guys, sorry for the confusion here, I messed up a bit.

When I say:

" 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 meant to say:

"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.e the EntityID does NOT have the "saml." Part of the URL. So the SP's signing certs subject name does NOT match the EntityID. Is this the cause? Is it possible to fix with configuration without swapping out the SP's signing certificate?

Best regards
Johan Åkerstrøm

From: users [mailto:users-bounces at] On Behalf Of Brent Putman
Sent: Wednesday, August 19, 2015 10:19 PM
To: users at
Subject: Re: Credential failed name check.

On 8/19/15 10:47 AM, Cantor, Scott wrote:
On 8/19/15, 10:34 AM, "users on behalf of Johan Åkerstrøm" mailto:users-bounces 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.

To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list