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 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 [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]