SP Requires Signed IdP Cert...

[Brent Putman]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20150130/33cc5908/attachment.html