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!
