asankha. I am using the javax.net.debug=all for all of my testing at this point. >From synapse when I encounter the hanging situation, it only occurs when my cacerts file contains the cert for the service that I am calling. It's a self-signed cert. If I use the virgin cacerts file that shipped with java 1.5 I get the general SSLEngine problem. I'll see what information that I can get about the target platform - it's not in my control and is hosted by another organization.
regards, griffin -----Original Message----- From: Asankha C. Perera [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 12:37 PM To: [email protected] Subject: Re: Outbound HTTPS with Client Certificate Hi Griffin I am able to reproduce your scenario where Synapse seems to stop responding, when a SSL handshake failure happens - and I am quite sure that its the same thing thats happening at your end too. If you run Synapse with -Djavax.net.debug=all this would be evident. Also if you are using the SVN trunk - get the latest code - I did a minute fix to the ClientHandler.java to print the stack trace that will help you debug the issue easily. Also check if you are getting the ClientHandler - I/O error: General SSLEngine problem in your logs? [I/O reactor worker thread 1] DEBUG Axis2HttpRequest - get source channel of the pipe on which the outgoing response is written .... I/O reactor worker thread 1, fatal error: 46: General SSLEngine problem sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target I/O reactor worker thread 1, SEND TLSv1 ALERT: fatal, description = certificate_unknown I/O reactor worker thread 1, WRITE: TLSv1 Alert, length = 2 I/O reactor worker thread 1, fatal: engine already closed. Rethrowing javax.net.ssl.SSLHandshakeException: General SSLEngine problem [I/O reactor worker thread 1] ERROR ClientHandler - I/O error : General SSLEngine problem That seems like a good idea. The interesting thing is that I didn't provide addressing headers to begin with, they seem to have been added by Synapse. Yes, this seems like a bug .. Could you please raise a JIRA for it, and we will fix it Also with regard to this endpoint, is there a way to control the protocol behaviours - i.e. disable Transfer-Encoding: chunked. No, this is left to the transport implementation to decide, and as we do not read the complete message from the wire into memory before we parse it, we do not know the size of the message - hence most of the time the chunked encoding is used. Same applies during a write as its possible that we do not know the size when we start to write the message to the wire. But this should have *no* impact on your application as its purely a transport decision. In my attempt to get the outbound HTTPS proxy to work, I've found that if I use SOAP-UI and configure the key and truststores as I have them with the Synapse/Axis2 httpniosslsender I am able to complete the request. The differences that I see in the debug streams are related to the HTTP header and the user of the Transfer-Encoding - the NIOSSL sender uses Transfer-Encoding: chunked and the Jakarta commons HTTP client used by SOAP-UI uses Content-Length: xxx instead. No I am positive that its not the chunked encoding, but the keystores.. I think its Synapse that doesn't trust your server. Could you tell me what your service host is? Is it Axis2/.net? and can does it use a self signed cert or CA cert? have you imported its cert or the CA cert into the trust store of Synapse?.. asankha --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
