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 <[EMAIL PROTECTED]> 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!
>
