We'd really need to update java.security.KeyStore to the 1.5 API to do that, though, because previous versions of the API only accepted an input stream for loading keystores.
On Jun 7, 2006, at 11:14 AM, Mark Wielaard wrote:
Hi Raif, I CCed the devjam list on which a couple of different distribution packagers are subscribed. Devjam people, Raif added support for importing trusted ca-certs to GNU Classpath so our tls/sslimplementation for example can just reuse the ca-certs that are alreadypackaged for an distribution (for example those used by Mozilla).Feedback on how to make this as easy as possible for distros appreciated(see below). Please forward to any distro-list when appropriate. On Fri, 2006-06-02 at 06:19 +1000, Raif S. Naffah wrote:On Monday 29 May 2006 21:21, Mark Wielaard wrote:On Mon, 2006-05-29 at 21:00 +1000, Raif S. Naffah wrote:On Monday 29 May 2006 20:02, Mark Wielaard wrote:On Mon, 2006-05-22 at 21:42 +1000, Raif S. Naffah wrote:my question is: does anybody see any problem, legal or otherwise, in including our version of this cacerts file which i named "cacerts.gkr" into the GNU Classpath distribution?I wonder how well that will work with the various distributions.if by distributions you mean the different VMs that use Classpath then this file is not much different than for example classpath.security, which is our version of java.security.No, I was thinking of the GNU/Linux distros. They seem to have their own collection of "trusted" ca-certs already. So I was wondering whether we could somehow reuse those easily (for example during installation time). That way a user has only one set of ca-certs to worry about. Since at least for Debian it seems every package using ssl uses the same set. http://packages.debian.org/ca-certificates And then we wouldn't have to worry which certificates to include and where they would come from.i downloaded and installed (own --prefix since i don't use a Debian distro) the latest stable ca-certificates package (from <http://packages.debian.org/stable/misc/ca-certificates>).Devjam people. Hints on how other distros handle this appreciated.i also added CACertCmd as a new command to the keytool --which does not have a counter-part in the RI version-- to import without prompting the user one x.509 certificate from a designated file. this new command isinvoked through: keytool -cacert ... a script, import-cacerts.sh, added to the scripts folder, recursively visits a given directory invoking the keytool -cacert command on each file with the following: * the alias of the certificate is constructed from the file name.* the key store password is hard-wired to 'changeit' --similar to the RIversion.* the key store is hard-wired to cacerts.gkr in resource/java/ security.Very nice! Please do check this in.all this allows us to build/update a key store of trusted certificates,which can then be included in our deliverables. the new '-cacert' command, although specific to our version of keytool is useful for sysadmins who may want to use something similar in their environment. comments?This seems perfect to let our users decide which cacerts they want touse themselves. If it all possible I would like to not actually ship any "trusted" ca-certs ourselves since that would put us in the position todecide which ca-certs are actually trusted and when to deprecate which ones for each release. So I would like to add a configure option (say --with-ca-cert-dir=/path/to/ca/cert/dir) which can be used by the user/packager to automatically run the import-cacerts.sh script during the build. Ideally each distribution would then add some package hooks to rerunimport-cacerts.sh for classpath whenever the ca-certificates package isupdated. I assume something like this is also used for Mozilla or OpenSSL. Devjam people? Cheers, Mark
PGP.sig
Description: This is a digitally signed message part
