Public key infrastructure

Tomas Mraz tmraz at redhat.com
Fri Jul 21 12:07:25 UTC 2006


On Fri, 2006-07-21 at 11:16 +0200, Joachim Selke wrote:

> (2) In order to check what certificates of communication partners can be
> trusted many applications can be given a list of CA certs that are
> trusted. Openldap, for example, uses configuration entries
> "TLSCACertificateFile" and "TLSCACertificatePath". The first entry
> refers to a file like ca-bundle.crt of the openssl package that contains
> a list of CA certs. The second entries refers to a directory that
> contains cert files.
> 
> My suggestion: Remove the default collection of trusted certs from the
> openssl package and create a new package for those certs. These certs
> then should be stored in /etc/pki/cacerts (one file per cert).
> Applications should use this by default as CA directory (openldap:
> "TLSCACertificatePath"). The file ca-bundle.crt is not needed anymore
> but should be there (in /etc/pki) for compatibility issues. In addition
> there should be a script that automatically creates this file from the
> contents of /etc/pki/cacerts. With cacerts in an extra package is it
> possible to use CA cert "modules". There could be other packages that
> contain futher CA certs. Every admin then can decide what certs to
> trust. This centralized directory /etc/pki/cacerts additionally makes it
> possible to add own CA certs without getting into trouble.
> 
> 
> What do you think about this?
I have a comment only about the cacerts situation. If I worked as admin
I'd never use all the ca certs shipped in the current CA bundle as
trusted for all apps. For web clients maybe, but for verification of
LDAP server certificate? Never. Most probably even an internal CA would
be used so I'd have to add its certificate anyway. So perhaps there
should be individual cacerts directories for individual apps.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb




More information about the fedora-devel-list mailing list