where 'o where to store certificates and keys

Bob Relyea rrelyea at redhat.com
Tue Apr 19 21:53:44 UTC 2005


>
>
>At the moment we have an ad hoc approach to where we store ssl
>certificates and other keys. The openssl package installs
>into /usr/share/ssl and some packages store their keys
>in /usr/share/ssl/certs/{public,private} because of the lack of anything
>better and its the closest thing we have to a standard location. Other
>packages (e.g. httpd) store their keys in their own directories.
>  
>
So the world is even *MORE* complicated that this.

Only about half our packages use openssl to get their SSL 
implementations. The other half uses NSS.
NSS store keys in in a keyX.db file and certs in certX.db. To make 
matters worst, like openSSL apps,
NSS apps typically store their own copy of the database somewhere in the 
user's profile.

I agree we need to solve this problem, but I think we need to take a 
step back and understand how
each application uses it's keys and certs. Just saying the keys and 
certs live in a particular directory
is not sufficient.

I wish I had seen this discussion earlier. It appears to have completely 
punted on applications that use NSS.

>There are three major reasons to create a new uniform location, and this
>is a proposal to do so:
>
>1) /usr/share is designed to be NFS mounted and shared. Private
>certificates and keys really should not be located by default in a
>directory visible to many machines on the network. /usr/share is an
>insecure location.
>
>2) SELinux labeling and policy authorship would be much easier and more
>robust if we collected certificates and keys in one place and label
>those files appropriately.
>
>3) Certificates and keys are not a property of the openssl package,
>there should be a package neutral location in the spirit of FHS to
>locate all certificate and key files which can be shared by all
>packages. Someplace in /etc seems ideal.
>
>Proposal: the filesystem rpm creates the following 3 new directories 
>
>/etc/keys
>/etc/keys/public
>/etc/keys/private
>  
>
This certainly is not going to work with existing NSS apps like 
evolution or Firefox.
They expect their key and cert databases to live in the same directory.

>Individual applications can make use of these directories in whatever
>fashion they desire, as long as the files they install there are
>certificates or keys of any form. They set their own permissions and
>ownerships.
>  
>
>I know this has been debated before, be we've got to make a decision and
>move forward (in part because this is now gating some work on my
>plate  :-) . I've had a hallway conversation with Nalin and Dan Walsh and
>it was agreed this was the most palatable option at the moment (not
>ideal, but a workable solution).
>  
>
Again, I wish I were in on this discussion. It seems to have missed a 
major component which affects
the overall design.

bob

>ACK's or NCK's please!
>
> -- John Dennis <jdennis at redhat.com> -- Fedora-maintainers mailing list 
> Fedora-maintainers at redhat.com 
> https://www.redhat.com/mailman/listinfo/fedora-maintainers
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3340 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20050419/eb2fee47/attachment.bin>


More information about the Fedora-maintainers mailing list