<html><head></head><body><div>I'm equally baffled at this point. I did another test with the v2 IDP against testshib, and it produces an identical result at this point. However as far as testshib is concerned, both IDPs give it information without error.</div><div><br></div><div>Since the metadata still referred to SAML1, and most of our providers are using that rather than SAML2, I tried chopping out all SAML2 references from metadata and giving testshib that, to try to force it to use that instead.</div><div><br></div><div>The results are particularly enlightening. While it still passes, the shibd.log results are a lot different. It seems that it tries to make a connection to the production Shibboleth at a different IP:</div><div><br></div><div><pre>015-07-16 11:54:05 DEBUG XMLTooling.SOAPTransport.CURL [73]: sending SOAP message to <a href="https://itfederation.jmu.edu:8443/shibboleth-idp/AA">https://itfederation.jmu.edu:8443/shibboleth-idp/AA</a>
2015-07-16 11:54:05 DEBUG XMLTooling.libcurl [73]: Trying 134.126.10.44...
2015-07-16 11:54:05 DEBUG XMLTooling.libcurl [73]: Connected to itfederation.jmu.edu (134.126.10.44) port 8443 (#0)</pre><pre><br></pre><pre>Then...</pre><pre><br></pre><pre>2015-07-16 11:54:05 ERROR OpenSAML.SOAPClient [73]: SOAP client detected a SAML error: (saml1p:Responder) (Error resolving principal)
2015-07-16 11:54:05 ERROR Shibboleth.AttributeResolver.Query [73]: attribute authority returned a SAML error</pre><pre><br></pre><pre><br></pre><pre><br></pre><pre>That might explain why it's failing, I had assumed I could fully test it with host file edits. Would this explain anything?</pre><pre><br></pre><pre>Thanks,</pre><pre><br></pre><pre>Brandon</pre></div><div><br></div><div><br></div><div>On Thu, 2015-07-16 at 15:30 +0000, Cantor, Scott wrote:</div><blockquote type="cite"><pre>On 7/16/15, 11:21 AM, "users on behalf of McKean, Brandon Scott - mckeanbs" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:mckeanbs@jmu.edu">mckeanbs@jmu.edu</a>> wrote:
<blockquote type="cite">
Hmm, I think I might have more information now, from testshib's log.
</blockquote>
The signature was fine, but the encryption was performed under the wrong key. In this case, you would have to have the wrong metadata for testshib, I guess.
That assumes testshib actually reported a failure. Nothing in that log was a definitive end result of anything.
<blockquote type="cite">
This would reinforce what you said before about it being a credential issue, but I'm not sure where that would be breaking down. The openssl commands I did before verified idp-signing.key and idp-signing.crt matched, and they are set as such in idp.properties.
</blockquote>
It evaluated your key just fine.
I am at this point lost as to who's failing, what's failing, and what the logs actually say because you've posted contradictory outcomes.
-- Scott
</pre></blockquote></body></html>