Great. I'll give it a try. -----Original Message----- From: Asankha C. Perera [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 1:48 PM To: [email protected] Subject: Re: Outbound HTTPS with Client Certificate
Hi Griffin If you are using SVN trunk, I have fixed the addressing issue - so unless you <enableAddressing/> on the endpoint, addressing will be disabled for outgoing messages. This was the behavior we already had, and we could improve this as Paul suggests with a JIRA asankha Michael Griffin wrote: 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. Also with regard to this endpoint, is there a way to control the protocol behaviours - i.e. disable Transfer-Encoding: chunked. 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. -----Original Message----- From: Paul Fremantle [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 11:17 AM To: [email protected] Subject: Re: Outbound HTTPS with Client Certificate Michael Seems like you might have found a flaw :-) At the moment we have a directive <enableAddressing/> in the endpoint definition, but we don't remove addressing headers if you already have them. How about we change the tag to <addressing enable="true|false|as-is"/> Paul On 3/9/07, Michael Griffin <[EMAIL PROTECTED]> wrote: asanka, The debugging reference was a big help - Thank you. I'm pretty sure that the HTTPS handshake and communication are working properly after looking at the debug output. The debug output raised another question for me though. For my endpoint defined as follows does indicate that I want to use WS-Addressing, yet it appears as if the actual message sent to the server does include this information - see the debug output which shows the soapenv:Header portion of the post. How can I suppress the wsa elements from being inserted into the header? Thanks, Griffin <definitions xmlns="http://ws.apache.org/ns/synapse";> <localEntry key="VRAPI.wsdl" src="file:repository/conf/sample/resources/proxy/VRAPI.wsdl" /> <endpoint name="VRAPI-1.0"> <address uri="https://api.verticalresponse.com/1.0/VRAPI"; format="soap"/> </endpoint> <proxy name="VRAPI" transports="http"> <target> <endpoint key="VRAPI-1.0"/> </target> <publishWSDL key="VRAPI.wsdl"/> </proxy> <!-- Log all messages passing through --> <log level="none"/> <!-- Send the messages where they have been sent (i.e. implicit "To" EPR) --> <send/> </definitions> 00E0: 20 20 20 3C 73 6F 61 70 65 6E 76 3A 48 65 61 64 <soapenv:Head 00F0: 65 72 3E 3C 77 73 61 3A 54 6F 3E 68 74 74 70 73 er><wsa:To>https 0100: 3A 2F 2F 61 70 69 2E 76 65 72 74 69 63 61 6C 72 ://api.verticalr 0110: 65 73 70 6F 6E 73 65 2E 63 6F 6D 2F 31 2E 30 2F esponse.com/1.0/ 0120: 56 52 41 50 49 3C 2F 77 73 61 3A 54 6F 3E 3C 77 VRAPI</wsa:To><w 0130: 73 61 3A 52 65 70 6C 79 54 6F 3E 3C 77 73 61 3A sa:ReplyTo><wsa: 0140: 41 64 64 72 65 73 73 3E 68 74 74 70 3A 2F 2F 77 Address>http://w 0150: 77 77 2E 77 33 2E 6F 72 67 2F 32 30 30 35 2F 30 ww.w3.org/2005/0 0160: 38 2F 61 64 64 72 65 73 73 69 6E 67 2F 61 6E 6F 8/addressing/ano 0170: 6E 79 6D 6F 75 73 3C 2F 77 73 61 3A 41 64 64 72 nymous</wsa:Addr 0180: 65 73 73 3E 3C 2F 77 73 61 3A 52 65 70 6C 79 54 ess></wsa:ReplyT 0190: 6F 3E 3C 77 73 61 3A 4D 65 73 73 61 67 65 49 44 o><wsa:MessageID 01A0: 3E 75 75 69 64 3A 75 72 6E 3A 75 75 69 64 3A 33 >uuid:urn:uuid:3 01B0: 32 36 43 33 44 41 46 32 43 37 44 45 33 42 38 41 26C3DAF2C7DE3B8A 01C0: 31 31 31 37 33 34 34 38 35 33 32 37 37 37 3C 2F 11173448532777</ 01D0: 77 73 61 3A 4D 65 73 73 61 67 65 49 44 3E 3C 77 wsa:MessageID><w 01E0: 73 61 3A 41 63 74 69 6F 6E 3E 56 52 2F 41 50 49 sa:Action>VR/API 01F0: 2F 31 5F 30 23 6C 6F 67 69 6E 3C 2F 77 73 61 3A /1_0#login</wsa: 0200: 41 63 74 69 6F 6E 3E 3C 2F 73 6F 61 70 65 6E 76 Action></soapenv 0210: 3A 48 65 61 64 65 72 3E 3C 73 6F 61 70 65 6E 76 :Header><soapenv 0220: 3A 42 6F 64 79 3E 0A 20 20 20 20 20 20 3C 76 72 :Body>. <vr -----Original Message----- From: Asankha C. Perera [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 6:52 AM To: [email protected] Subject: Re: Outbound HTTPS with Client Certificate Hi Griffin It appears to be listening for requests (and serving WSDL) on http and it also appears to delegate the call back to the https implementation. but from that point it basically stalls at with this log message [I/O reactor worker thread] DEBUG Axis2HttpRequest - get source channel of the pipe on which the outgoing response is written and finally times out. It appears to me that something is going wrong with the SSL handshake to the backend service. If I use a truststore without the ca cert for the server I am calling, I get an SSL error. But if I use different keystore with incorrect client certificates, i don't get any messages. Is there a way to diagnose the SSL handshake component in more detail? Try the debugging tips found here -> http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.htm l#De bug I am pretty sure this is a SSL configuration issue, can you verify that your trust store contains the certificate used by server.somedomain.com or its CA cert as a trusted certificate entry? Also the same on that server side, you could debug SSL and see if it receives the client certificate from Synapse, and if it has the certificate that Synapse presents (as the client) in its trust store, or the CA of the Synapse certificate is trusted by it etc. If that server based on Java? If so you could run both with those system properties to find out whats going wrong.. my guess is that your server rejects the certificate presented by Synapse.. asankha --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
