SP Requires Signed IdP Cert...

[Andrew Devenish-Meares]

Thanks all for the reply, seems I'm misunderstanding what the Back-channel.  I'm talking about the initial SSO.  The SP passes to our IdP, the user signs on, attributes are resolved and the message sent back to the SP is signed with the certificate I'm trying to use.  Seems I have a bit more reading to do on the back-channel stuff. 

Thanks for the wiki reference, I'll take a look at that.

Cheers

Andrew

--
Andrew Devenish-Meares
Solutions Analyst
Information Technology
University of New England
Armidale   NSW   2351

e:  adevenis at une.edu.au
p:  02 6773 4098
w: http://une.edu.au/itd
________________________________________
From: users-bounces at shibboleth.net [users-bounces at shibboleth.net] on behalf of Brent Putman [putmanb at georgetown.edu]
Sent: Friday, 30 January 2015 5:04 PM
To: users at shibboleth.net
Subject: Re: SP Requires Signed IdP Cert...

On 1/30/15 12:24 AM, Andrew Devenish-Meares wrote:



We have a vendor who is insisting that we need to us a signed
certificate for back-channel communications between their SP and our
IdP.  We are running IdP 2.4.2.


Jumping ahead a little: Below you talk about what you are configuring and seeing in the signature, but above you mention back-channel, which I interpret to mean the cert used on the back-channel SOAP listener in e.g. Apache/Tomcat/Jetty.  Those are going to be different.  The back-channel is easy, standard server/container config - except that you might need 2 back-channel ports, right?  One with self-signed cert for most of the SP's, and a second with the non-self-signed cert?  Unless I'm misunderstanding.



 After consultation, they suggested it
should be possible to configure a second certificate for this specific
provider.


For XML signatures, yes, that's the way to do it.




But their SP fails to process the login with the error
"Message was signed, but signature could not be verified."

We'll assume that they've done the right things on their end and the root CA is trusted, as a KeyAuthority in metadata, etc.



It would seem, as it's not logged, that the intermediate certificate
isn't being presented.


Ok.  I think I know why that is.  OpenSAML is perfectly capable of emitting the whole cert chain represented in the credential, but the default config on the relevant KeyInfoGeneratorFactory doesn't actually do it.  We just emit the entity cert.  At the moment I can't think of any good reason not to change the default config to emit the whole cert chain.  Most of the time (with self-signed certs) the change will have no effect, but when it's not self-signed and you have intermediates, it really should include them.





I've tried putting both the server and intermediate certificates into
the same file, which will verify on the command line with openssl, but
this also fails to work.

No, that won't work.





Any suggestions, other than telling the vendor that they're being difficult?

Well, feel free to tell them they're being difficult. :-)


But yes, I believe we can do this.  I'll think about changing the defaults on that, for the future. In the meantime, you can have control over the global security config via the Spring extension bean mentioned here:

https://wiki.shibboleth.net/confluence/display/SHIB2/Changing+IdP+Signature+Method+Algorithm

That page is specifically about configuring SHA-256 signatures, and doesn't mention the KeyInfo generation stuff that you need, but the same extension class (Spring FactoryBean) does support this.  It's a bit late here, but tomorrow I will come up with the Spring bean wiring config that you'll need, and post it back here and/or on the wiki.


--Brent