"javax.net.ssl.keyStore" system property inside a jar package

[adrian wardell]

I am developing an application that must connect to an http server using ssl (https). During testing without packaging the application as a jar file everything works fine. As I am using the following code to specify the keystore file:
System.setProperty("javax.net.ssl.trustStore", "/absolute/file/location/java/application/keystore");
But when the code gets put into a jar file and tranfered to another machine with a different file system layout... how do I set the system property in a machine independant way?
Please someone help me on this one, as I've been banging my head way too long...

[Dirk Schreckmann]

Welcome to JavaRanch, adrian!
This is probably a little bit above the concerns of a typical Java greenhorn. I'm moving this to the intermediate forum...

[Nils Larsgard]

I have the same problem as the thread starter. Is there a clean way of doing this?

[Santhosh Kumar]

Unfortunately the javax.net.ssl.trustStore property cannot read the data from classpath but expect it to be a file path. So it means there is no machine independent way to specify the path.

Best way is to take the below line,

System.setProperty("javax.net.ssl.trustStore", "/absolute/file/location/java/application/keystore");

out of your code base and specify property using command line while starting the JVM as below.

java -Djavax.net.ssl.trustStore=<file> -jar your.jar

[Norm Radder]

The general question is how to find the location of a file on a new/different system.
1) If you know the filename, you could search all possible paths.
2) Ask someone where it is when you install the program and save it's location somewhere. Does Preferences do this?

[Nils Larsgard]

The thing is that I won't know the exact location because the keystore is inside a jar file for a web-start application. I could force the users of the application to install a certificate on their local vm, but this is not very user-friendly.

However, I tried something like this code, but it doesn't work. Am I on to something here?

  
TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
InputStream keystoreStream = ClassLoader.getSystemResourceAsStream("./myTruststore.jks ");
keystore.load(keystoreStream, "mypassword".toCharArray());
trustManagerFactory.init(keystore);
TrustManager[] trustManagers = trustManagerFactory.getTrustManagers();
SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, trustManagers, null);
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

[Nils Larsgard]

Ok. I gave up this strategy. Instead, this made it work:

read the keystore file as a resource stream :MyClass.class.getClassLoader().getResourceAsStream(jarCertFile);

write it to localhost

set truststore property to local file, System.setProperty("javax.net.ssl.trustStore",trustStore);

[ July 09, 2008: Message edited by: Nils Magnus Larsg�rd ]

[Paul Donohue]

@Nils Lasgard:
Your code above works for me. I'm not sure why it didn't work for you.

You can also use:
SSLContext sc = SSLContext.getInstance("TLS");
instead of:
SSLContext sc = SSLContext.getInstance("SSL");
I'm not sure if that makes any difference (it works for me either way).

And you can also use:
SSLContext.setDefault(sc);
instead of:
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
to use the specified trust store for all SSL connections rather than just HttpsURLConnections.

[Campbell Ritchie]

Welcome to JavaRanch

Are you sure he is still reading after 15 months? Look at this FAQ.

[Andreas Pax Lück]

@Campbell Ritchie:

no, but there are many other guys who search the internet to solve the same problem and are glad to get as much as information that are necessary. in other words: every post might be helpfull and the date of postings doesn't matter in these cases.

best regards

PAX

[Campbell Ritchie]

Point taken, and welcome to JavaRanch

[b hoff]

Larsgard's code snippet helped me out a lot (and was very clever). To get it working I had to make a few small changes. Here's my revision:

	private static final String DEFAULT_JAVA_KEYSTORE_PW = "changeit";
	private static final String KEYSTORE_NAME = "HttpClientHelperPublicCertsOnly.jks"; // no leading "./".  I think that would be system dependent
	private static final HttpClient httpClient;

	static {
		try {
			TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
			KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
			InputStream keystoreStream = HttpClientHelper.class.getClassLoader().getResourceAsStream(KEYSTORE_NAME); // note, not getSYSTEMResourceAsStream
			keystore.load(keystoreStream, DEFAULT_JAVA_KEYSTORE_PW.toCharArray());
			trustManagerFactory.init(keystore);
			TrustManager[] trustManagers = trustManagerFactory.getTrustManagers();
			SSLContext ctx = SSLContext.getInstance("TLS"); // was SSL
			ctx.init(null, trustManagers, null);
			
			SchemeSocketFactory ssf = new SSLSocketFactory(ctx);  
			
			SchemeRegistry schemeRegistry = new SchemeRegistry();
			schemeRegistry.register(new Scheme("http", 80, PlainSocketFactory
					.getSocketFactory()));
			schemeRegistry.register(new Scheme("https", 443, ssf));
			schemeRegistry.register(new Scheme("https", 8443, ssf));
	

			ThreadSafeClientConnManager connectionManager = new ThreadSafeClientConnManager(
					schemeRegistry);
	
			HttpParams clientParams = new BasicHttpParams();
			clientParams.setParameter(CoreConnectionPNames.CONNECTION_TIMEOUT,
					DEFAULT_CONNECT_TIMEOUT_MSEC);
			clientParams.setParameter(CoreConnectionPNames.SO_TIMEOUT,
					DEFAULT_SOCKET_TIMEOUT_MSEC);
	
			httpClient = new DefaultHttpClient(connectionManager, clientParams);
		} catch (KeyStoreException e) {
			throw new RuntimeException(e);
		} catch (KeyManagementException e) {
			throw new RuntimeException(e);
		} catch (NoSuchAlgorithmException e) {
			throw new RuntimeException(e);
		} catch (CertificateException e) {
			throw new RuntimeException(e);
		} catch (IOException e) {
			throw new RuntimeException(e);
		}
			
	}
	

[Campbell Ritchie]

Welcome to the Ranch
It shows how useful old posts can be.

[H Paul]

Campbell Ritchie wrote:Welcome to the Ranch
It shows how useful old posts can be.

Resurrection.

[Opher Shachar]

For me too this was extremely useful.
That's 7 years since @Nils Larsgard's post

(I registered just to leave this post!)

[Campbell Ritchie]

Welcome to the Ranch

If you look at the link I posted many years ago, you will see we have changed our tune: we now recognised the potential usefulness of old posts and how they can be rediscovered ten years later and still provide valuable information.