Debian Developers - RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]

Author

RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]

James Westby

2006-07-28, 1:23 am

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:
>
> 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/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

James Westby

2006-07-28, 7:29 am

On (28/07/06 10:03), Lars Wirzenius wrote:
> pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti:
>
> How badly is this tied to debhelper? Any chance of designing it so that
> it doesn't require debhelper?
>

Why does this concern you? I thought debhelper was fairly standard use
today.

But, yes, like all of debhelper it's just a convenience wrapper. If your
package is very simple then in the postinst add

if [ "$1" = "configure" ]; then
make-ssl-cert2 package
fi

and in postinst

if [ "$1" = "purge" ]; then
make-ssl-cert2 -r package || true
fi

The dh_ script merely does this for you after adding any extra arguments
to make-ssl-cert that you have requested with your
debian/package.certificate file.

So, if you are merely concerned that it is /possible/ to do it without a
dh_ call, then it certainly is. But I think it is a good idea to use it,
as if the "policy" changes in this respect then a rebuild is all that
may be required. And also it gives the maintainer more chance that any
problems can simply be reassigned to someone else.

James Westby

[P.S. I have put the source in bzr format here
http://jameswestby.net/bzr/ssl-cert2/ so it's browsable over the web
now]

--
James Westby
jw+debian@jameswestby.net
http://jameswestby.net/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

James Westby

2006-07-28, 7:29 am

On (28/07/06 13:16), Lars Wirzenius wrote:
> pe, 2006-07-28 kello 10:53 +0100, James Westby kirjoitti:
> I don't like it when people make using helper packages de facto
> required. And debhelper isn't standard (meaning that you can expect
> everyone to use it), merely very common. It is also very good, but its
> use must still remain optional.

That is fair enough. I understand the desire for choice.

>
>
> Good. If that is documented in the ssl-cert2 package, then all is well.
>

http://jameswestby.net/bzr/ssl-cert2/README

Probably requires updating to the new make-ssl-cert2 options.

--
James Westby
jw+debian@jameswestby.net
http://jameswestby.net/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org