That's funny because that's what I did and just posted a little write up on my logical progression from diagnosing the problem in case it's helpful for others.
On 9/12/07, Fred Dushin <[EMAIL PROTECTED]> wrote: > > Depending on what underlying HTTP transport implementation you are > using, you can try setting the javax.net.debug system property to > "all". This is a standard way to diagnose underlying SSL issues in > the JSSE. > > On the client side, CXF uses the HTTPURLConnection class, which will > use the JSSE to do the SSL handshake, so you should be all set on the > client side. > > On the server side, the Jetty HTTP implementation also uses the JSSE, > so again, you should also be able to use that system property to get > a trace of the SSL handshake (to stderr or stdout -- forget which off > the top of my head). > > Short of that, the s_client and s_server commands to openssl are > invaluable tools for diagnosing issues with SSL handhsakes. man > openssl on your local *BSD or (halfway decent) Linux distro, or go > straight to [1]. > > That, at least, is my standard operating procedure. > > Hope it helps, > -Fred > > [1] http://www.openssl.org/docs/apps/openssl.html > > On Sep 12, 2007, at 9:30 AM, Ryan Moquin wrote: > > > I'm still running into my SSLHandshake problems no matter what I > > do, but I > > seem to have no problem using the Apache HTTPClient to send a raw SOAP > > request of SSL to the same server. Both are using the same > > keystore and as > > far as I can tell the same SSL configuration (which is very > > little). Is > > there something, anything, I can do to trouble shoot this kind of > > problem? > > Is there something CXF would need above what a normal java ssl > > application > > would need? > > > > Thanks! > >
