intermittent error - NoHttpResponseException - client cert related?
843811Aug 5 2009 — edited Aug 6 2009I have a custom SOAP client that fails intermittently. The exception thrown is
org.apache.commons.httpclient.NoHttpResponseException: The server xxxxx failed to respond
This is using 1.4.1_02. I was hoping to get my hands on the JSSE source for that build so that I can research why this failure is occurring, but I'm not having any luck finding it.
The error is intermittent in that a specific request may throw this exception a few times, but then eventually work.
The SOAP service does require that the client submit a client certificate. The client cert is in our keystore and it is usually sent along just fine. The keystore is attached to the application using Djavax.net.ssl.keyStore=<path to keystore>
I've gone over the the SOAP service trace logs with the vendor and the client debug logs and have spotted a specific difference between success and failure. On successful calls, the server never receives the client certificate, but the client instead attempts to begin to post content to the server. The problem is that the server is waiting for a client certificate and the client is waiting for the server to acknowledge receipt of posted content (at this point this is just the content-length header). Both ends are in a "wait" state and the client ends up throwing this exception.
I've tried adding -Djavax.net.debug=ssl to my client application to see what's going on. In comparing a success and failure, the log for the success includes some lines that are absent in the failure log:
*** CertificateRequest
Cert Types: RSA,
Cert Authorities:
<stuff>
*** ServerHelloDone
matching alias: 00922b852bfd4bd869d373bd48df9c43_37613357-3410-43b9-8fbd-0d9011f6d1c6
matching alias: d710b9fe4034f8c78228892aa1fd28e4_93d6efe1-6fc8-4301-8da1-93d74c773a77
I believe this is related to the client sending the client certificate.
At the equivalent part of the log for failure there are these items before the *** ServerHelloDone
Thread-21, received EOFException: ignored
Thread-21, called closeInternal(false)
Thread-21, SEND TLSv1 ALERT: warning, description = close_notify
Thread-21, WRITE: TLSv1 Alert, length = 18
Thread-21, called close()
Thread-21, called closeInternal(true)
Thread-21, called close()
Thread-21, called closeInternal(true)
Invalidating the session
%% Invalidated: [Session-9, SSL_RSA_WITH_RC4_128_MD5]
Thread-21, called close()
Thread-21, called closeInternal(true)
setSoTimeout(300000) called
setSoTimeout(300000) called
%% No cached client session
*** ClientHello, TLSv1
RandomCookie: GMT: 1249430519 bytes = { 103, 174, 159, 83, 201, 183, 231, 197, 187, 109, 189, 78, 121, 17, 67, 146, 31, 25, 85, 216, 73, 240, 116, 173, 104, 198, 58, 0 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods: { 0 }
***
Thread-21, WRITE: TLSv1 Handshake, length = 73
Thread-21, WRITE: SSLv2 client hello message, length = 98
which I think are related to the client attempting to post data to the server without first submitting the client certificate.
The behavior makes it seem like either the server is not sending the request for the client certificate or else the client is not noticing the request for the client certificate. Since the web service vendor has not encountered this problem with any other client, I'm leaning toward the fault being with the client.
My biggest questions:
1 - Has anyone experienced anything like this?
2 - What could cause this situation?
3 - How can this be fixed?
4 - How can I find the JSSE source for 1.4.1_02? (I'd like to step through the code or add more debugging.)
Thanks,
Neal