You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Andre Piwoni <ap...@megawest.com> on 2002/05/06 21:22:39 UTC

SSL and Axis

Instructions for setting up Apache SOAP Client for SSL communication at
http://xml.apache.org/soap/docs/install/FAQ_Tomcat_SOAP_SSL.html are
fine, however, the following line in the SOAP client,
 
System.setProperty("javax.net.ssl.trustStore","C:\\jdk1.3\\bin\\client.k
eystore")
 
make it unusable when deployed with Java Web Start or as an applet as
far as I know.
 
One solution, I thought, would be to send client.keystore in .jar file
along with application and to point javax.net.ssl.trustStore to location
in .jar file which I couldn't accomplish successfully. Whathever reads
this property apparently does not know how to read .jar files.
 
Second solution that came to my mind was to load client.keystore into
instance of KeyStore class and initialize SSLContext with it as shown
below:
 
      TrustManagerFactory tmf =
TrustManagerFactory.getInstance("SunX509", "SunJSSE");
      tmf.init(keyStore);
 
      SSLContext context = SSLContext.getInstance("TLS");
 
      context.init(null, tmf.getTrustManagers(), null);
 
HttpsURLConnection.setDefaultSSLSocketFactory(context.getSocketFactory()
);
 
However, designers of SSLUtilities class that builds SSLSocket in
ApacheSOAP use SSLSocketFactory factory =
(SSLSocketFactory)SSLSocketFactory.getDefault(). This method creates new
SSLContext  which uses default keystore so my second idea didn't work
out.
 
Why do we are required to have client authentication in Apache SOAP at
all? Why not allow more control over SSLContext?
 
Is there any way to get around these limitations?
 
Thanks!