RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
Warning, long email.
Executive summary.
==================
* More consistent handling of SSL certs would be nice.
* The proposed ssl-cert package is not in good shape.
ssl-cert2 from http://jameswestby.net/debian/ssl-cert2-0.1.tar.gz
aims to
* Make it easier for package maintainers
- One extra dh_ call and maybe one more file in debian/
* Allow the admin more choice in managing these certs, a choice of
- Ignore it completely, have a cert generated without any hassle,
and all SSL applications working out of the box.
- Have one certificate, and use a single command to regerate it
(with values of your choice).
- Have a sitewide certificate of your choice with one command.
- Have a sitewide certificate, but individual certificates where
needed (for multiple apache domains perhaps).
- Have individual certs for everything with one command (and maybe a
few answers to prompts).
- Turn it off completely, run your own CA, create certificates when
needed (and prodded that a new package will require a
certificate).
=========================================
On (30/06/06 10:51), Jaldhar H. Vyas wrote:
> In bug #376146, Martin Pitt wrote:
> > In an effort to clean up the SSL certificate mess on Ubuntu servers, we
> > recently converted all our supported Server packages to make use of
> > the ssl-cert package instead of creating a package-specific
> > self-signed SSL certificate. This allows admins to easily replace the
> > certificate with a 'real' one without touching dozens of configuration
> > files, and also provides a consistent setup out of the box.
>
> Is this is a good idea for Debian? I think it is but it doesn't make sense
> to switch dovecot over unless all the other ssl-cert using packages also do
> it. Is this possible in the etch timeframe?
>
This thread generated some interest and discussion of the ways this
could be done, so I looked in to how suitable it was to convert all of
the packages. What I found was that there weren't many packages in
Debian using ssl-cert. Most worrying was that the maintainers of apache
and ssl-cert had stopped using it.
Looking at the ssl-cert package it seems that it has plenty of problems,
(e.g. #230485, #230791), and it doesn't implement the system discussed
in this thread.
To this end I decided to write a package myself to do the job. It is
called ssl-cert2, it's not based on ssl-cert at all, but I couldn't
think of an original name.
I wanted to try and get some discussion about the architecture I have
gone for, as I am sure I haven't though of everything.
So, firstly it implements a system of symlinks that I think was the
consensus in this thread, i.e. it creates
ssl-cert2-sitewide.pem -> ssl-cert2-snakeoil.pem
so that the one symlink can be updated to change the certificate for all
services. Each package then gets a link pointing at the -sitewide one,
so that these links can be changed if the admin wants a separate cert
for some service.
One of the big complaints about ssl-cert was it's use of debconf, so I
have tried to minimise this usage. There are debconf questions to create
the snakeoil certificate, but at medium priority. I wanted to keep this
so that preseeding might help out an admin later. My plan is to have a
standalone program that manipulates the certificates.
The default of this new package is therefore to link all certs to a
central self-signed cert with guesses for CN and email ($(hostname) and
root@$hostname), and the debconf value from d-i for country if
available. This should be enough for most packages to run, and the aim
is to make it changeable by a single command to what the admin wants.
The plan is to have a script that allows all of this to be managed
easily, so you can do something like.
manage-ssl-cert2 regenerate-sitewide
which will prompt for values and recreate the snakeoil certificate (with
a --no-prompt option to just regenerate if it expires or similar).
also
manage-ssl-cert2 replace-cert sitewide /some/cert
to drop in a replacement (signed by a CA or similar).
The system then does it's best to not interfere, for instance not
changing/making a link if it points somewhere that the program doesn't
think it can change without the admin's permission (by storing readlinks
from the links when they were created). There could well be a --force
option to make it ignore this and do it anyway.
As for the packages themselves, the idea is that they merely add
dh_sslcert2 to debian/rules, and assume that their certificates are
created. The idea is that the system will place them there if the admin
hasn't told it not to (for instance by turning off ssl-cert2 completely,
which is very easy to do).
They can also use debian/package.certificate files to set some
preferences for how they would like their certificates. Notably the
locations, but also owner, group etc., which will be respected if the
admin configures ssl-cert2 to use individual certs (which we will get to
in a second). It might also be possible for the package to request that
it must have an individual certificate for some reason, but I am
undecided as to whether this is a good idea yet.
The commands from above could also have package specific versions as
well, so that you could have,
manage-ssl-cert2 replace dovecot /some/cert
for example.
The admin could also do
manage-ssl-cert2 config packages
which would then generate certificates for each package registered with
it, and update the symlinks to use those instead. (There would also be
config sitewide to switch back).
The main drawback I can see is that the snakeoil cert key (or any
replacement cert key) would have to be owned byu the ssl-cert group, and all
users requiring access to this key would have to be part of this group.
I am unsure of the security implications of this, but I don't think they
are too great.
So, in summary the system aims to
* Make it easier for package maintainers
- One extra dh_ call and maybe one more file in debian/
* Allow the admin more choice in managing these certs, a choice of
- Ignore it completely, have a cert generated without any hassle,
and all SSL applications working out of the box.
- Have one certificate, and use a single command to regerate it
(with values of your choice).
- Have a sitewide certificate of your choice with one command.
- Have a sitewide certificate, but individual certificates where
needed (for multiple apache domains perhaps).
- Have individual certs for everything with one command (and maybe a
few answers to prompts).
- Turn it off completely, run your own CA, create certificates when
needed (and prodded that a new package will require a
certificate).
So, thanks to all those that made it down this far. Do you have any
comments on the design of the system?
You can see the work so far at
http://jameswestby.net/debian/ssl-cert2-0.1.tar.gz
though it is far from ready, and probably doesn't even work yet. Note
the packaging is currently native, and the insertion of the lib in to
the script will be removed, I just haven't done it yet.
Thanks,
James
--
James Westby
jw+debian@jameswestby.net
http://jameswestby.net/
Reply to: