Credential failed name check.

[Johan Åkerstrøm]

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

When I say:

" EntityID of the RP is: https://saml.site.domain.com but the signing cert has the following subject: 'OU=oiosaml-sp,CN=https://saml.site.domain.com' is this mismatch what is causing the error?"

I meant to say:

"EntityID of the RP is: https://site.domain.com but the signing cert has the following subject: 'OU=oiosaml-sp,CN=https://saml.site.domain.com' 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 shibboleth.net] On Behalf Of Brent Putman
Sent: Wednesday, August 19, 2015 10:19 PM
To: users at shibboleth.net
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 shibboleth.netonbehalfofJohan.Akerstrom@skill.no wrote:



I'm getting this error.

2015-08-19 16:12:47,308 - WARN [org.apache.xml.security.signature.XMLSignature:760] - Signature verification failed.
2015-08-19 16:12:47,312 - ERROR [org.opensaml.security.x509.impl.BasicX509CredentialNameEvaluator:300] - Credential failed name check: [subjectName='OU=oiosaml-sp,CN=ht
tps://saml.site.domain.com']

EntityID of the RP is: https://saml.site.domain.com but the signing cert has the following subject: 'OU=oiosaml-sp,CN=https://saml.site.domain.com' 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:

org.opensaml.security.x509.impl.BasicX509CredentialNameEvaluator

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.