[cp-patches] Re: RFC: add a cacerts file under resource/java/security

Casey Marshall csm at gnu.org
Wed Jun 7 20:15:12 UTC 2006

One nice way to do this ca-certs stuff is to write a "keystore"  
implementation that just reads certificates out of a directory, and  
with each certificate stored in its own file. This would make it a  
lot easier for Classpath to use the certificates already installed on  
the system (like Debian's ca-certificates package). If there is a  
common way most GNU/Linux distros package certs, we'd do good to take  
advantage of that.

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/ssl
> implementation for example can just reuse the ca-certs that are  
> already
> packaged 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 is
>> invoked 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 RI
>> version.
>> * 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 to
> use 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 to
> decide 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 rerun
> import-cacerts.sh for classpath whenever the ca-certificates  
> package is
> updated. I assume something like this is also used for Mozilla or
> OpenSSL. Devjam people?
> Cheers,
> Mark

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 478 bytes
Desc: This is a digitally signed message part
Url : http://developer.classpath.org/pipermail/classpath-patches/attachments/20060607/10b30d3d/PGP.pgp

More information about the Classpath-patches mailing list