<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 1/30/15 12:24 AM, Andrew
Devenish-Meares wrote:<br>
</div>
<blockquote cite="mid:54CB157E.5040605@une.edu.au" type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:54CB157E.5040605@une.edu.au" type="cite">
<pre wrap=""> After consultation, they suggested it
should be possible to configure a second certificate for this specific
provider.
</pre>
</blockquote>
<br>
For XML signatures, yes, that's the way to do it.<br>
<br>
<br>
<blockquote cite="mid:54CB157E.5040605@une.edu.au" type="cite">
<pre wrap="">
But their SP fails to process the login with the error
"Message was signed, but signature could not be verified."</pre>
</blockquote>
<br>
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. <br>
<br>
<blockquote cite="mid:54CB157E.5040605@une.edu.au" type="cite">
<pre wrap="">
It would seem, as it's not logged, that the intermediate certificate
isn't being presented.</pre>
</blockquote>
<br>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:54CB157E.5040605@une.edu.au" type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<br>
No, that won't work.<br>
<br>
<br>
<blockquote cite="mid:54CB157E.5040605@une.edu.au" type="cite">
<pre wrap="">
Any suggestions, other than telling the vendor that they're being difficult?</pre>
</blockquote>
<br>
Well, feel free to tell them they're being difficult. :-)<br>
<br>
<br>
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:<br>
<br>
<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/SHIB2/Changing+IdP+Signature+Method+Algorithm">https://wiki.shibboleth.net/confluence/display/SHIB2/Changing+IdP+Signature+Method+Algorithm</a><br>
<br>
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. <br>
<br>
<br>
--Brent<br>
<br>
<blockquote cite="mid:54CB157E.5040605@une.edu.au" type="cite">
</blockquote>
<br>
</body>
</html>