 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / May 2006truststore in jar?
Scenario: Java application distributed as a single jar file. It now needs to make SSL connections where it used to make TCP connections. So it needs a truststore so as to be able to validate the certificate presented by the server. I've got all that working fine with the truststore in a separate disk file, but that's no use for distributing the application. So, if I include the truststore in the jar file (along with the images and other resource files) how do I make the Java SSL system use it? (The only suggestion I've found is to include it as a resource, then write some code to copy this to a disk file before setting the system property. This is nonsense, mostly because it is obviously utterly silly but also because it's less than obvious that you can guarantee to find somewhere to put the file safely and reliably.) -- Tim Ward Brett Ward Limited - www.brettward.co.uk > So, if I include the > truststore in the jar file (along with the images and other resource files) > how do I make the Java SSL system use it? You can do it by getting a javax.net.ssl.SSLContext via SSLContext.getInstance, then call SSLContext.init(). The second parameter is an array of TrustManagers. You can define your own TrustManager to load your truststore from wherever you like, using in your case java.security.KeyStore.load() from your truststore resource's input stream, and implement the X509TrustManager API to respond appropriately when SSL asks you any of those questions by looking in that KeyStore. You then use that SSLContext to obtain your SSL socket factories, use them to get your SSLSockets, and away you go. However having said all that I would probably recommend that you rethink the strategy instead. What happens when your server certificate expires? Another software distribution? What about those clients you aren't able to reach with your distribution any more, for whatever reason? do you really want to cut them off at the knees? All your clients really need in their truststores is a root certificate to which your server certificate leads, and actually Java's truststore should already have one of those. It ships with lots of root certs for Verisign, CyberTrust, Equifax, Baltimore,Entrust, GeoTrust, Thawte, &c, and your certificate is almost certainly signed by someone whose cert chain leads back to one of those. > > So, if I include the > > truststore in the jar file (along with the images and other resource files) [quoted text clipped - 4 lines] > parameter is an array of TrustManagers. You can define your own > TrustManager ... I was beginning to think that was probably the way forward ... thanks for confirming it. (Before I'd written lots of code trying out various wrong approaches.) > However having said all that I would probably recommend that you rethink > the strategy instead. What happens when your server certificate expires? > Another software distribution? Well, not when any individual server certificate expires, only when the private root certificate is compromised ... in which case another distribution of my little application will be the least of my client's worries. > What about those clients you aren't able > to reach with your distribution any more, for whatever reason? do you > really want to cut them off at the knees? Not my decision, I just implement the spec. But the answer could well be something like: "yes, cutting them off is fine, because if they can't be reached for a software distribution they probably also can't be reached to be billed for their support contract". > All your clients really need in their truststores is a root certificate > to which your server certificate leads, and actually Java's truststore > ...ships with lots of root certs ... > and your certificate is almost certainly signed by someone whose cert > chain leads back to one of those. Nope, it's a private certificate hierarchy. Thanks again. -- Tim Ward Brett Ward Limited - www.brettward.co.uk > > So, if I include the > > truststore in the jar file (along with the images and other resource files) [quoted text clipped - 9 lines] > that KeyStore. You then use that SSLContext to obtain your SSL socket > factories, use them to get your SSLSockets, and away you go. ... except that I don't want to try to understand how to write code to "implement the X509TrustManager API" because all that code already exists: I don't want any different algorithms to what's built in, only different data. Instead, why can't I: (1) get a TrustManagerFactory (2) make a KeyStore and load it from the resource as you say (3) use this KeyStore to init() the TrustManagerFactory (4) get the TrustManagerFactory to make me a TrustManager (5) pass this to SSLContext.init() and continue as you say ie, instead of writing code to implement X509TrustManager, get one from a customised TrustManagerFactory? In which case, all I need to know is which version of TrustManagerFactory.instance() to call and what parameters to pass it in order to obtain a TrustManagerFactory that will behave in exactly the same way as the default one except that it's got a different set of trusted root certificates? Ah, probably I just pass it getDefaultAlgorithm()? -- Tim Ward Brett Ward Limited - www.brettward.co.uk >>> So, if I include the >>> truststore in the jar file (along with the images and other resource [quoted text clipped - 34 lines] > Tim Ward > Brett Ward Limited - www.brettward.co.uk You may find the following article interesting: <http://www.devx.com/tips/Tip/30077> Obviously you don't need the GUI. But it shows a pretty minimal implementation of an X509TrustManager Regards, Rogan > Instead, why can't I: > [quoted text clipped - 4 lines] > > ... This all sounds OK, stupid of me not to think of it. > > Instead, why can't I: > > ... [quoted text clipped - 4 lines] > > This all sounds OK, stupid of me not to think of it. For any future readers of this thread: that does in fact work. -- Tim Ward Brett Ward Limited - www.brettward.co.uk Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.