<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 8/19/15 10:47 AM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:49810ACF-3902-4C7B-AD4B-5D7FEE31D979@osu.edu"
type="cite">
<pre wrap="">On 8/19/15, 10:34 AM, "users on behalf of Johan Åkerstrøm" <a class="moz-txt-link-rfc2396E" href="mailto:users-bounces@shibboleth.netonbehalfofJohan.Akerstrom@skill.no"><users-bounces@shibboleth.net on behalf of Johan.Akerstrom@skill.no></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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: <a class="moz-txt-link-freetext" href="https://saml.site.domain.com">https://saml.site.domain.com</a> but the signing cert has the following subject: 'OU=oiosaml-sp,CN=<a class="moz-txt-link-freetext" href="https://saml.site.domain.com">https://saml.site.domain.com</a>' is this mismatch what is causing the error?
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<br>
Agreed. If you aren't intending to do PKIX trust, then the key(s)
in the SP's metadata is the problem.<br>
<br>
<br>
<blockquote cite="mid:49810ACF-3902-4C7B-AD4B-5D7FEE31D979@osu.edu"
type="cite">
<pre wrap="">
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,</pre>
</blockquote>
<br>
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<br>
<br>
<br>
<blockquote cite="mid:49810ACF-3902-4C7B-AD4B-5D7FEE31D979@osu.edu"
type="cite">
<pre wrap=""> and the entityID ought to be an implicitly trusted key name, </pre>
</blockquote>
<br>
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).<br>
<br>
<br>
<blockquote cite="mid:49810ACF-3902-4C7B-AD4B-5D7FEE31D979@osu.edu"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
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.<br>
<blockquote cite="mid:49810ACF-3902-4C7B-AD4B-5D7FEE31D979@osu.edu"
type="cite">
</blockquote>
<br>
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:<br>
<br>
org.opensaml.security.x509.impl.BasicX509CredentialNameEvaluator<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
</body>
</html>