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="" class="moz-txt-link-rfc2396E" href="file:repository/conf/sample/resources/proxy/VRAPI.wsdl">"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.html#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]
