Hi Markus,

Apologies if I'm not quite getting the crux of your problem - I'm new to all this and I've only recently tried using ssl, and at the moment I'm really just playing with it. I have no problems connecting over both http and https, even in the same client program.

In my client program I have defined the keyStore and trustStore by setting properties:

System.setProperty("javax.net.ssl.trustStore", "/home/richard/clientKeystore");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
System.setProperty("javax.net.ssl.keyStore", "/home/richard/clientKeystore");
System.setProperty("javax.net.ssl.keyStorePassword", "changeit");

I have one service locator (generated by wsdl2java) which has a http address (port 8080) for a service running on my local machine, and another which has a https (port 8443) addresss for the service. Within the same client program I can invoke the service by instantiating both of these, and everything works as fine - I guess the properties above are just ignored when connecting over http.

BiorsMetaDataDocStyleServiceLocator service = new BiorsMetaDataDocStyleServiceLocator(); BiorsMetaDataDocStyleServiceLocator1 service1 = new BiorsMetaDataDocStyleServiceLocator1();

BiorsMetaDataPortType port = service.getBiorsMetaDataDocStyle();
BiorsMetaDataPortType port1 = service1.getBiorsMetaDataDocStyle();

Databanks banks = port.getDatabanks("ibi", "mips");
Databanks banks1 = port1.getDatabanks("ibi", "mips");

I haven't tried to also connect to another service requiring different keys, but if these were in the same client key/trustStore would this not also work?

I hope this helps - apologies if it doesn't.

Richard.

Markus Reil wrote:

Hi,

thanks for your answer, Tim.
I also thought reimplementing the Sender class would be a solution, but I hoped being able to avoid it.

As I already pointed out I am connecting to other WS from the same VM that do not require SSL authentication (everything is plain http). Can anyone please tell me how I can programmatically specify different client config wsdd files for different services?

Thank you.

Markus

Tim R J Langford wrote:

Hi Markus,

Did you manage to find a solution to your problem? I had to do something similar once with a test system to get it to accept non certified sites across ssl. I could not work out how to do do it correctly in Axis; so I ended up creating a custom HTTPSender and setting it up as my pivot in the handler chain of Axis. I extended the base HttpSender class from Axis, but a lot of variables and methods I wanted to overide were private, so unfortunately I ended up having to cut and paste most of the extending class into the new class and am not sure of the implications of this evne though everything seemed to work fine.

If you use this method then you can pretty much alter the HTTP mechanism as you see fit: for example allowing you to support gzip compression (I think originally axis did not support this from what I remember?). You can also use this class to overide the SocketFactory and get it to produce a non-certified sockets if you so desire. Infact this method maybe overidable... I cant remember. If not maybe it should be.

Anyway, I am sure there is a more maintainable way of doing this, but I was in a rush and it was a while ago. If you are in the same situation maybe a simialr approach will get you by for now?


Hope this helps until you find something more suitable,

Tim



Markus Reil wrote:

Hi,

I am currently trying to connect to a SOAP Web Service with Axis. I need to use a client certificate to authenticate myself. I do not want to set the keystore/truststore files globally via system properties because I have other http traffic in the same virtual machine that uses different or no keys.

I know there are a lot threads out about Axis/SSL out there. But I already spent a couple of hours looking for a solution and did not find anything of great use. Can anyone help me with this?

E.g. is it possible to create a SocketFactory and pass it to the Axis Service or Remote instance?

Thanks.

Regards,
Markus



Reply via email to