Backchannel attribute query vs. SSL handshake error

[Misagh Moayyed]

Thought I'd report on what the resolution turned out to be:

1. Made sure port 8443 was explicitly set in the configuration. For some
reason, jetty didn't fall back to the default value that was there for the
port, when the property key was missing. Outright weird. 

2. Made sure JCE was installed, (we are running with JRE 8), and turned up
SSL debugging per Marvin's suggestion. 

3. And, it turned out that the backchannel keystore was missing the
private key; Java of course made no effort to make that diagnosis clear :)


Thanks for the suggestions. I may end up documenting this experience on
the wiki under the troubleshooting guide. 

-- Misagh

> -----Original Message-----
> From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor,
> Scott
> Sent: Friday, July 31, 2015 9:20 AM
> To: Shib Users <users at shibboleth.net>
> Subject: Re: Backchannel attribute query vs. SSL handshake error
> 
> On 7/31/15, 1:27 AM, "users on behalf of Misagh Moayyed" <users-
> bounces at shibboleth.net on behalf of mmoayyed at unicon.net> wrote:
> 
> >Attempts to connect to the idp from the SP via openssl: "openssl
> >s_client -cert ./sp-cert.pem -key ./sp-key.pem -connect
> >idp.example.org:8443 -debug -msg -state" reports back SSL handshake
> >errors. Attempts to connect to the idp from the idp machine itself with
> >the same exact command works successfully.
> 
> That usually suggests an issue with the interface(s) it's actually
> listening on, there really isn't anything else that could apply to give
> you different results with the same OpenSSL client.
> 
> If nmap -p 8443 from off-host reports the port is open, then I guess one
> possibility would probably be something else listening on the port and
not
> Jetty.
> 
> -- Scott
> 
> --
> To unsubscribe from this list send an email to users-
> unsubscribe at shibboleth.net