where 'o where to store certificates and keys

John Dennis jdennis at redhat.com
Tue Apr 26 21:20:26 UTC 2005


On Wed, 2005-04-20 at 18:34 -0400, Alan Cox wrote:
> On Wed, Apr 20, 2005 at 03:08:56PM -0400, John Dennis wrote:
> > On Wed, 2005-04-20 at 12:42 -0400, Bill Nottingham wrote:
> > > I'd think /etc/pki is more practical.
> > 
> > Done, the name is chosen and the directory /etc/pki has been added
> > making its appearance in filesystem-2.3.2-1.
> 
> Cool - is it worth submitting that proposal to the FSSTND people ? Its
> a multi-vendor issue and "where to put keys" will become an app issue more
> and more over time.

I promised I would do this and I followed up right away. I got the
following response today from Thorsten Kukuk at SuSE on the
freestandards-fhs-discuss at lists.sourceforge.net list where I had posted.
I'm sharing this folks here in fedora land. Active discussion of this
should probably take place on the FHS mailing list (above) and not a
fedora specific list. I will try to be a bridge for simple issues.

John

--------------------------------------------------------------

Hi,

I like the ida and SuSE/Novell is willing to follow such a specification
in our next products, too. I added the comments of some of our
developers
below. 

On Thu, Apr 21, John Dennis wrote:

> We propose (and actually have just implemented in Fedora Core 4) that
> the directory /etc/pki (for Public Key Infrastructure) be created as a
> root location for keys and certificates. It is recommended that each
> service create a subdirectory named after itself under /etc/pki and
that
> it store its certificates, keys, etc. in its own subdirectory
> under /etc/pki.

[Some developers suggested to use /etc/ssl, since this is what
 OpenSSL already uses].

In general a good idea.

We have to differ between two types of certificates.

1. The Server Certificate (and private Key) for a service
   (like http server, mail server, vpn, etc.)

2. A set of trusted (root) CA Certificates (and corresponding CRLs).

Also one very common scenario is, that there is one server certificate
for all
services (or more that one) on a host.

I do not know if it is required to have more than one set of trusted CA
certificate. In case of doubt the answer is yes:-)
Openssl has a default for this directory to /usr/ssl/certs/ .

I think with the following proposal we could achieve the above topics.

/etc/pki/
         common/
                trustedCerts/
                serverCert/
         <name>/
                trustedCerts/
                serverCert/

"common" directory:
  used, if an administrator wants to use server certificates and/or
trusted CA
  certificates for more than one service


"<name>" directory:
  used for a dedicated service

"trustedCerts" directory:
  used for a set of trusted (root) CA certificates and CRLs

"serverCert" directory:
  used for the server certificate and the private key

---

Another comment was:

One should also distinguish between:
- - the "default"/out-of-the-box use of /etc/ssl/certs to contain all
kinds of root CA certificates so that SSL client certificates can be
verified
- - the PKI use of OpenSSL where you generate your own certs.

In an ideal world, I don't want my CA's certificates to be mixed with
those root certificates, at least not physically. In my setup, I put
them in a seperate subdirectory "own" (could also be named "pki" or
"default_CA") and put symlinks into /etc/ssl/certs instead.

One could of course also turn it around: use /etc/ssl/certs for own
certificates and put the root certs in /etc/ssl/certs/root-CAs or
something like that.

As for the name /etc/pki itself, I prefer /etc/ssl since this is a more
specific term (= a directory related to OpenSSL) than PKI (= a
particular use of OpenSSL).

> [...]
> Please note, the keys and certificates which would reside in /etc/pki
> are for system supplied services (e.g. mail servers, web servers, ssh,
> etc.). It is not intended as a repository for per user keys.

A similar directory layout could be created in ~/.local or ~/.ssl or
~/.pki ...

  Thorsten





More information about the Fedora-maintainers mailing list