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
[EMAIL PROTECTED]), 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
