This is my plan for how to improve the way SSL certficates are handled in Debian.

Current state

Mostly each package that requires a certificate creates one. This may involve prompting the user for the values, and is work to make sure it is being done correctly.

For the user it is difficult to manage these certificates, as there is nothing that ties them together, and no common way of doing this.

The ssl-cert package aims to solve some of these problems, by allowing the packages the chance to use it to do the work, and the use of a central certificate (sometimes). However this package is buggy and not used very much.

It was suggested in this thread that we encourage packages to use the ssl-cert package, and several ideas were put forward about how the idea could be extended.


A new ssl-cert2 package which aims to solve the above problems. I paste below my email to debian-devel about the proposal, which aims to give an overview.

> 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).


  1. Implement more of the necessary functionality.
  2. ITP ssl-cert2.
  3. Get the package in good shape.
  4. Try and find a sponsor for upload to experimental.
  5. Play around with the packages that can use it and come up with something that works for them all.
  6. File wishlist bugs against the packages with patches.
  7. Wait for the bug reports to roll in.

Currently I am at stage 1. I hope to be at around 5/6 for etch, so that it's not in a stable release yet, and doesn't get in the way of the release. I might have to wait for longer if everybody is too busy with etch. However, you never know, it might all go well and get done before then.

The current sources will located under I will be using bzr for development if anybody wants to help out.