Backchannel failing after upgrade

Cantor, Scott cantor.2 at
Thu Jan 12 21:46:49 EST 2017

On 1/12/17, 3:33 PM, "users on behalf of James Drews" <users-bounces at on behalf of james.drews at> wrote:

>    Well, I'll go dig what version the SP is, but it's odd that on the same host using the same openssl program (Version:
> OpenSSL 1.0.1t  3 May 2016) when using one cert/key pair it fails, but another cert/key pair works. So I wouldn't think it is
> a library issue on the SP end.

1.0.1 shouldn't have any problem connecting. And you should be able to connect with no key, the back channel should be set up with wantClientAuth, not needClientAuth, and with the special trust plugin that makes it accept any key. Partly to allow for signed messages, where the security isn't via client cert. But using any key should work, and the failure should occur inside the IdP after it tries to decode the message, and be logged there. A total failure to connect simply doesn't match the expected behavior.

I don't know what you mean by another key working. If anything is working, then there shouldn't be any issue here, but in all cases it should be reaching IdP code and getting logged, or it has to be a handshake error with the client, and if the SP is seeing that, then *that* should get logged by the SP.

>    I'm also having our SP guy look into the question of why is it even using the backchannel (attribute fetch?)....

SAML 2 doesn't need it and SAML 1 doesn't need to be used. You're either doing artifacts, or you don't need that port, at least for basic SPs doing SSO.

> I'll also mention, that if I use the non-working cert and connect to port 443 (same jetty engine), that works. So there is
> something else in the backchannel rejecting it.  

Port 443 doesn't look at the client cert. Port 8443 just evaluates it *if* it's presented and only inside the IdP. At least that is what was supposed to be shipped, and certainly nobody else has said that it's not doing that, but I suppose we're seeing less and less actual usage of the feature too.
-- Scott

More information about the users mailing list