[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Managing SSL certificates



On Sat, Oct 15, 2005 at 03:10:50PM +0300, Lars Wirzenius wrote:
> With my testing of packages in etch with piuparts[1], I occasionally run
> into a problem that occurs in many packages in the same way. One such
> problem is the creation and deletion of SSL certificates for various
> services (imaps, https, etc). At the moment, the packages tend to create
> the certificate automatically on installation, if it isn't there
> already, and not remove it when the package is purged. This leaves cruft
> on the filesystem.
> 
> A couple of problematic scenarios that have been brought up:
> 
>         * What if the sysadmin modifies the certificate? For example,
>         they might add a signature from a CA, or replace it with a
>         completely new one.
>         
>         * What if the certificate is shared by several packages?
>         
> There are probably others.
> 
> In my opinion, it would be nice to be clean about these certificates so
> that if I install a package and then purge it, without touching the
> certificate in any way, it is removed with the package. While the amount
> of cruft left behind by these files is pretty small, it's still cruft.
> 
> My suggestion would be to create a tool to manage installation and
> removal of certificates. Something like this:
> 
>         update-ssl-certificate --create package servicename
>         update-ssl-certificate --remove package servicename

Such a tool would be very nice, and not just because of the cruft they
leave behind -- many packages currently support SSL connections; some
automatically generate a self-signed certificate upon installation,
others leave that to the admin. Some use debconf to ask information for
the certificate (or to warn that a certificate has to be generated
before SSL will be enabled), some don't.

A unified API to clean up this mess would be very interesting.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond



Reply to: