W3C home > Mailing lists > Public > www-jigsaw@w3.org > May to June 2003

Changes to the SSLAdapter and SSLSocketClientFactory

From: Laird, Brian <BLaird@perseco.com>
Date: Tue, 20 May 2003 11:09:39 -0500
Message-ID: <45A6279F82E4CA4BBDC0F4EFC7B6A2FE6FEA31@atlas.perseco.com>
To: <www-jigsaw@w3.org>
Cc: "Arora, Pankaj" <PArora@perseco.com>, "EXODUS LOG" <EXODUSLOG@perseco.com>, "Hady, Jeff" <JHady@perseco.com>, "Michalak, Michael" <MMichalak@perseco.com>, "Ying, Christy" <CYing@perseco.com>, "Mrozinski, Ken" <KMrozinski@perseco.com>
Description of problem:
We wanted to have multiple services/listeners running with in a jigsaw server.  We also wanted to have a different certificate for each service.  Due to the initial implementation of the SSL protocol, it only supported one certificate for all services.  The reason we found that is that the SSLAdapter was setting the keystore information to the system properties.  So as each service was created, it was overwriting the system properties.  What we found was that once the SSL factory (javax.net.ssl.SSLServerSocketFactory) had been created, it would NOT reread the system properties to pick up the new keystore.

Fixes made:
- in the SSLSocketClientFactory:
	1 - made the ServerSocketFactory (variable name is factory) an instance variable
	2 - removed the initialization of the factory from the constructor to the initialize() method
	3 - instead of calling the getDefault on the SSL factory, we now use the SSLContext to create the factory.  This allows us to use the different keystores specified.  (example code used: http://developer.java.sun.com/developer/technicalArticles/Security/secureinternet/ )
	
- in the SSLAdapter
	1 - in the initializeProperties method, we commented out the keystore & truststore system property assignments.

Notes / Assumptions:
- I didn't bother to fix the propertyChanged event methods for either SSLAdapter or SSLSocketClientFactory because from what we could tell it looks like you would have to tear down the entire service and rebuild it and that currently isn't being done.  Since that was our assumption, we figured it didn't matter since a restart would be necessary.  Please let us know if we missed something.   I will be happy to fix those correctly, otherwise I would suggest commenting those out or throwing an exception so that the user in admin module knows that it will need a restart
- We assumed that the keystore and truststore would be the same file.  I understand this may not be the case for a few, but we couldn't really see a reason why it wouldn't be in this application of SSL (meaning acting as an SSL server).  
- We assume that each service/listener will have it's own keystore.  If you have one keystore, with multiple aliases or certs, we will only read the first one.  This seems to be the default for the JDK 1.4.1, and I haven't found a good example of how to pull out a specific alias.
- We assume that the password for the keystore is the same for the certificate.  If someone has a case where that is not the same, let me know I can rework the code to handle that.

Please let me know if anyone has any questions or comments.  Also if the attached files don't come through let me know and I can resend the source.  Yves or Thomas, if you could let me know when this might be added to the CVS and nightly builds, that would be great.

Brian



 <<SSLSocketClientFactory.java>>  <<SSLAdapter.java>> 



Received on Tuesday, 20 May 2003 12:10:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 12:13:36 GMT