Credential failed name check.

[Johan Åkerstrøm]

" That explains that part, but the point remains, your metadata's wrong. If you put the right key into the metadata for the SP, it will work regardless, so just do that and you're done."

I get your point. But this is the metadata generated from the SP. It is the SP generating the wrong Subject Name. So. Guess I have to go down the PKIX route meanwhile. 
Any pointers to how to setup PKIX for additional TrustNames in Idp 3.0? I'm not the best of friends with the documentation to figure this out myself.

"No, the wrong key in the metadata is the cause. The effect of that is to fall into PKIX logic. If you want that deliberately, that's a bad idea, but making that work with that particular certificate would require adding the CN of that certificate into the metadata as a ds:KeyName and adding KeyAuthority extension (something Shibboleth invented) to express the CA/root."

I understand it is a bad idea, but I don't have control over the cert which the SP is signing with. The SP is signing with a cert with the inhjected "saml." part. There is a feature of uploading a JKS or PKCS12 into the SP. While talking to the vendors support team they themselves have never used it and it doesn't work. 
And just a few seconds ago I went through the logs of the SP and found out that the form which is sending the keystore to the SP is not not working. I am somewhat 80% confident the vendor has a bug there. 

That leaves me with PKIX. Where do I implement it? Which config file and under which parent elements? Can I control PKIX in such a way that it only will apply for a certain relying partiy?


Best Regards
Johan Åkerstrøm
 
Løsningsarkitekt, Skill AS
Tlf: +47 91850043 | E-post: ja at skill.no | Web: www.skill.no 
 
«Deres forretning - vår lidenskap»
-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Thursday, August 20, 2015 3:50 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Credential failed name check.

On 8/20/15, 8:32 AM, "users on behalf of Johan Åkerstrøm" <users-bounces at shibboleth.net on behalf of Johan.Akerstrom at skill.no> wrote:

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

That explains that part, but the point remains, your metadata's wrong. If you put the right key into the metadata for the SP, it will work regardless, so just do that and you're done.

Otherwise you're using the PKIX code, and you don't want to do that.

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

No, the wrong key in the metadata is the cause. The effect of that is to fall into PKIX logic. If you want that deliberately, that's a bad idea, but making that work with that particular certificate would require adding the CN of that certificate into the metadata as a ds:KeyName and adding KeyAuthority extension (something Shibboleth invented) to express the CA/root.

> Is it possible to fix with configuration without swapping out the SP's signing certificate?

Yes, put it in the metadata.

-- Scott

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