Setting certificates file with Tomcat / SOAP

[As...@BTFinancialgroup.com]

Hello everyone,

Our application runs under Tomcat 3.3.1 using in-process IIS and uses SOAP 2.3. It initiates client B2B communications with an external vendor server using SSL (J2SE 1.4) and SOAP. My problem is that I cannot load our certificates file by setting a default SSLSocketFactory, the comms only work when I specify the certificates file through setting the javax.net.ssl.trustStore system property. I believe that Tomcat/SOAP interferes with the SSLSocketFactory that I set as default.

I have some test code which :
1 - Creates a SSLSocketFactory by loading our certificate file into the KeyStore via a FileInputStream.
2 - Sets that SSLSocketFactory as the default on HttpsURLConnection.
3 - Creates a URL (using https, ie SSL protocol) pointing to our external vendor.
4 - Tests the URL by opening its stream and reading.
5 - Uses the URL to invoke a SOAP call on our external vendor.

This test code runs fine when executed outside of Tomcat (ie as a simple Java class). However, when I run it under Tomcat, step 4 works (and uses our certificate file), but step 5 fails because it does not use our certificate file. Very strange! This leads me to believe it is a Tomcat and SOAP problem.

Relevant output from SSL log:
	trustStore is: No File Available, using empty keystore
	Thread-14, SEND SSL v3.1 ALERT:  fatal, description = certificate_unknown 


Note that:
- The connections all work fine when I specify the location of the certificates file using the javax.net.ssl.trustStore system property, and not going through the business of creating and setting the default SSLSocketFactory. However, we cannot use this system property as it is not secure for us to have our certificates file residing on our webserver.
- I have disabled all inbuilt Tomcat SSL support (ie Http10Connector, etc) but it still seems to override my default SSLSocketFactory. This part of our application is not running though https coming in to our website from a client, but rather from within our application initiating a https session with another remote application. 
- I have also deleted the default JRE certificates file (on purpose!).

I believe that Tomcat / SOAP is somehow resetting our default SSLSocketFactory back to a standard one which simply reads the location of the certificate file from the system property. How can I stop it from doing this?

(Test code is included below)

Thanks,

Ashley Bryett
BT Financial Group


		System.setProperty("javax.net.debug", "all");
		Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());

		//  Set the certificate file rather than use an environment varible
		char[] passphrase = "passphrase".toCharArray();

		SSLContext ctx = SSLContext.getInstance("SSL");
		KeyStore ks = KeyStore.getInstance("JKS");
		ks.load(new FileInputStream("C:/ServerApps/Sysdata/cacerts"), passphrase);

		KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
		kmf.init(ks, passphrase);

		TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
		tmf.init(ks);

		ctx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);

		SSLSocketFactory factory = ctx.getSocketFactory();

		HttpsURLConnection.setDefaultSSLSocketFactory(factory);
		HttpsURLConnection.setDefaultHostnameVerifier(new ApatheticHostnameVerifier());

		URL url = new URL("https://"+TESTURL);

		java.io.InputStream in = url.openStream();
		while (in.read() >= 0)
			{ }
			
		// create the transport
		SOAPHTTPConnection st = new SOAPHTTPConnection();

		// build the call.
		Call call = new Call();
		call.setSOAPTransport(st);
		call.setTargetObjectURI(JDV_URN);
		call.setMethodName(METHOD);
		call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);
		call.setParams(params);

		// invoke it
		Response resp = call.invoke(url, null);

		// check response
		if (!resp.generatedFault())
		{
			Parameter ret = resp.getReturnValue();
			String retStr = ret.getValue().toString();
		}

------------------------------------------------------------------------------
This message and any attachment is confidential and may be privileged or otherwise protected from disclosure.  If you have received it by mistake please let us know by reply and then delete it from your system; you should not copy the message or disclose its contents to anyone.





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>