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