[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Public key infrastructure

Hash: SHA1

seth vidal wrote:
>> I think there should be a consistent behavior regarding /etc/pki.
> would you be willing to go through all the packages in extras and core
> and find the ones and what they're doing?

Here we go.

   * It is created empty by the filesystem package.

   * It is created by the fedora-release package and contains the
     package certificates of the standard yum repositories.

   * They are created empty by the openssl package. I think they are
     intended to be used for a local certificate authority. If so, then
     /etc/pki/CA/private/ contains the keys generated. Maybe a directory
     for storing public certs is missing.

   * They are created by the openssl package. I am not sure what
     /etc/pki/tls/ is supposed to contain. By its name I assume that is
     should contain all "TLS related stuff". But I think it is hard to
     decide what certs used on the system are solely "TLS related" and
     what not.
   * /etc/pki/tls/certs/ contains the file ca-bundle.crt, a collection
     of trusted certificate authorities. This file is taken over from
     Mozilla and Red Hat certificate have been added to it.
     Unfortunately this directory also contains a Makefile and a script
     for creating certificates. This should be placed in
   * /etc/pki/tls/private/ is created empty. I think it is intended to
     contain private keys.
   * /etc/pki/tls/misc contains a collection of simple scripts used for
     working with certificates (create hash value, get infos about
     certs, ...).

Now we look at all applications using /etc/pki:

   * This file is created by openldap-servers. I think that in general
     it is a bad idea if packages come with default certificates.
     Certificates should be included or generated by the admin.

   * This one is created by dovecot. It contains a openssl example
     config file for creating dovecot certs. It also comes with default
     certs in subdirectories certs/ and private/. Again, I think that
     default certs are a bad idea.

   * This dir is created empty by pure-ftpd.

   * This dir is created by cyrus-imapd. It contains a default cert

   * These files are created by uw-imap. Again, we have default certs.

   * These directories are created by the nessus-server package and
     contain some default certs.

   * This default cert comes with libnasl

   * It comes with bittorrent and contains a cert.

Now we have a short look at packages not using /etc/pki. Most of them
should use it in my opinion.

   * This dir is created empty by openldap.

   * This dir contains certificate related stuff (certs and tools) from
     the freeradiu package.

   * This dir is created by the cups package. I don't know what it is
     used for.

   * This dir contains a collection of certs and it created by

   * Created empty by ipsec-tools.

   * Created containing some files by the psi package. I don't know what
     it is for.

   * These directories contain many certs and tools, created by the
     erlang package.

   * These directories contain many certs and tools, created by the
     compat-erlang package.

   * This dir is created empty by the dirmngr package.

   * Created empty by the plague package.

   * Created empty by the plague-builder package.

   * This dir is created by the cone package and contains many trusted
     CA certs.

   * By the pl package and contains some certs.

   * Both files are created by the exim package.

   * Some files of the puppet package.

   * These dirs contain some cert related scripts of the openvpn

As you see there is a large variety on how packages store their
certificate related stuff. I think there should be created some
guidelines that make clear how and where to store digita certificates.
Here are some suggestions:

(1) Many applications have a own certificate used for crypted
communication (e.g. TLS). Usually it is split it two files (public and
private part) that must be specified in the apllication's config files.
Openldap, for example, uses the config commands "TLSCertificateFile" and
"TLSCertificateKeyFile" for this. Other apps do it in a similar way.

My suggestion: Every application that uses digital certificates should
create a directory /etc/pki/$appname with subdirectories "public" and
"private" where its certificates are stored. The default config files of
these applications should reflect this by corresponding entries
(commented out). Additionally the /etc/pki/tls/ should be removed from
the openssl package since certs should not be stored there.

(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?

- --
B. Sc. Joachim Selke
Universität Hannover, Institut für Theoretische Informatik
Appelstraße 4, 30167 Hannover, Germany
Version: GnuPG v1.4.4 (GNU/Linux)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]