You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Ryan Moquin <fr...@gmail.com> on 2007/09/12 15:30:56 UTC
How do you troubleshoot SSL problems with CXF?
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!
Re: How do you troubleshoot SSL problems with CXF?
Posted by Ryan Moquin <fr...@gmail.com>.
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 <fr...@dushin.net> 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!
>
>
Re: How do you troubleshoot SSL problems with CXF?
Posted by Fred Dushin <fr...@dushin.net>.
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!
Re: How do you troubleshoot SSL problems with CXF?
Posted by Ryan Moquin <fr...@gmail.com>.
Ok, luckily I solved my problem and since it has frustrated me to no end for
the last 2 days, I discovered a good way to debug SSL communication problems
for CXF. This is a little long, but I feel that it's important and may be
useful to others. If not, then oh well.
The first thing I did, was to create some code to communicate with the
secured URL that doesn't use CXF so I can verify my java ssl setup, such as
like this (yes it's crude, but it's just throw away code):
********************************************************************
private void sendRawRequest() throws Exception {
PostMethod method = null;
try {
InputStream test = Thread.currentThread
().getContextClassLoader().getResourceAsStream("test_soap.xml");
StringBuffer s = new StringBuffer();
InputStreamReader reader = new InputStreamReader(test);
int c = 0;
while((c=reader.read()) != -1) {
s.append((char)c);
}
reader.close();
HttpClient client = new HttpClient();
method = new PostMethod(url);
System.out.println("Connecting to url: " + url);
method.setQueryString(s.toString());
int statusCode = client.executeMethod(method);
InputStream is = method.getResponseBodyAsStream();
s = new StringBuffer();
reader = new InputStreamReader(is);
c = 0;
while((c=reader.read()) != -1) {
s.append((char)c);
}
reader.close();
is.close();
System.out.println(s.toString());
}catch(Exception ex) {
ex.printStackTrace();
throw ex;
}finally {
method.releaseConnection();
}
}
********************************************************************
Now this will let you see if your java SSL config is correct without CXF
interference. Since this worked in my case, it seemed to be a CXF problem
(hence my emails regarding it the last few days). Since I have a working
and none working instance, I finally decided I need to find a way to examine
the SSL communication with the server from the simple java app and from the
CXF app. I discovered that if you pass in this parameter to the JVM:
-Djavax.net.debug=all
You'll see the client and server talking back and forth attempting to
negotiate the SSL connection. So when I did this for both client's, I saw
with the CXF client:
********************************************************************
[Raw read]: length = 5
0000: 15 03 01 00 02 .....
[Raw read]: length = 2
0000: 02 28 .(
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1 ALERT: fatal, handshake_failure
main, called closeSocket()
********************************************************************
and I saw with the normal java client:
********************************************************************
[Raw read]: length = 5
0000: 16 03 01 00 4A ....J
[Raw read]: length = 74
0000: 02 00 00 46 03 01 91 0B 6B C0 B4 1A B6 79 D7 48 ...F....k....y.H
0010: F2 FB 9A 1D DB CD 45 A6 5B AE 03 3D 64 7D CE 79 ......E.[..=d..y
0020: 1A B4 60 0A 75 34 20 D4 8E 18 4D 80 73 19 98 4B ..`.u4 ...M.s..K
0030: DA 6F 29 E7 1B A3 5E E4 D2 29 C3 F0 FE 52 4E 95 .o)...^..)...RN.
0040: C7 AB C1 C9 E5 64 56 00 04 00 .....dV...
main, READ: TLSv1 Handshake, length = 74
*** ServerHello, TLSv1
RandomCookie: GMT: -1861522752 bytes = { 180, 26, 182, 121, 215, 72, 242,
251, 154, 29, 219, 205, 69, 166, 91, 174, 3, 6
1, 100, 125, 206, 121, 26, 180, 96, 10, 117, 52 }
Session ID: {212, 142, 24, 77, 128, 115, 25, 152, 75, 218, 111, 41, 231,
27, 163, 94, 228, 210, 41, 195, 240, 254, 82, 7
8, 149, 199, 171, 193, 201, 229, 100, 86}
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5
Compression Method: 0
***
%% Created: [Session-2, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
********************************************************************
So obviously the server told CXF to eat it. At this point, I looked to see
what happened in the simple java app after the point at which the handshake
exception occurred with CXF. The main thing is that an encryption algorithm
was selected:
(%% Created: [Session-2, SSL_RSA_WITH_RC4_128_MD5].
This prompted me to look back at the default list of cypher filters that CXF
printed. This algorithm name was NOT listed. So I added it to my
cxf.xmlconfig:
<sec:cipherSuitesFilter>
<sec:include>SSL_RSA_WITH_RC4_128_MD5</sec:include>
<sec:include>SSL_RSA_WITH_RC4_128_SHA</sec:include>
</sec:cipherSuitesFilter>
CXF was then able to negotiate the SSL connection.
Hopefully this little writeup was helpful and while it might seem a little
overkillish, I'm hoping that maybe using that debug param will help others
having SSL problems to get past their problems quickly and move on.
On 9/12/07, Ryan Moquin <fr...@gmail.com> 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!
>