Re: RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti: * Make it easier for package maintainers - One extra dh_ call and maybe one more file in debian/ How badly is this tied to debhelper? Any chance of designing it so that it doesn't require debhelper? -- One does not see anything until one sees its beauty. -- Oscar Wilde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
On (28/07/06 10:03), Lars Wirzenius wrote: pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti: * Make it easier for package maintainers - One extra dh_ call and maybe one more file in debian/ 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 [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
pe, 2006-07-28 kello 10:53 +0100, James Westby kirjoitti: On (28/07/06 10:03), Lars Wirzenius wrote: pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti: * Make it easier for package maintainers - One extra dh_ call and maybe one more file in debian/ 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. 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. But, yes, like all of debhelper it's just a convenience wrapper. If your package is very simple then in the postinst add Good. If that is documented in the ssl-cert2 package, then all is well. -- The most difficult thing in programming is to be simple and straightforward. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
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. But, yes, like all of debhelper it's just a convenience wrapper. If your package is very simple then in the postinst add 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 [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
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
Re: Using the SSL snakeoil certificate
On Sun, Jul 23, 2006 at 08:37:50PM +0200, Martin Schulze wrote: Milan P. Stanic wrote: Sorry if I misunderstand something, but is it okay to call it snakeoil if it is real certificate? I like to say that the symbolic links for per-service certificate shouldn't point to something called snake-oil. Nah, if you replace the snakeoil certificate by a real one, it's not snake-oil anymore, of course. But then you must change all symlinks to that new real certificate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
On Mon, 24 Jul 2006, Milan P. Stanic wrote:
On Sun, Jul 23, 2006 at 08:37:50PM +0200, Martin Schulze wrote:
Milan P. Stanic wrote:
Sorry if I misunderstand something, but is it okay to call it snakeoil
if it is real certificate? I like to say that the symbolic links for
per-service certificate shouldn't point to something called snake-oil.
Nah, if you replace the snakeoil certificate by a real one, it's not
snake-oil anymore, of course.
But then you must change all symlinks to that new real certificate.
That's why on my systems all the service names symlink to
thishost.{pem,key} and that is itself a symlink to the current
certificate. Only one symlink to update when you rotate certs.
Peter
--
| .''`. ** Debian GNU/Linux **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `-http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
On Mon, Jul 24, 2006 at 12:43:16PM +0200, Peter Palfrader wrote:
On Mon, 24 Jul 2006, Milan P. Stanic wrote:
But then you must change all symlinks to that new real certificate.
That's why on my systems all the service names symlink to
thishost.{pem,key} and that is itself a symlink to the current
certificate. Only one symlink to update when you rotate certs.
That is what I'm thinking about. All service certificates should be
symlink to one generic name (as Martin proposed) but that name
shouldn't be snake-oil because the meaning of the word snake oil, IMO.
thishost.{pem,key,crt,p12} looks better.
Another idea is to make that decision to user/admin during installation
through debconf or something similar, but don't ask me for patch
because I don't know how to make it. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
Milan P. Stanic wrote: For example: Dovecot uses /etc/ssl/certs/dovecot.pem. This is a symbolic link to /etc/ssl/certs/ssl-cert-snakeoil.pem if the above file or link does not exist during configuration of dovecot. That way, the admin can easily replace the symlink with a real certificate if they want per-service certificates. If, however, they want to have one real certificate for everything, they can replace the snakeoil certificate like Martin Pitt proposed. Sorry if I misunderstand something, but is it okay to call it snakeoil if it is real certificate? I like to say that the symbolic links for per-service certificate shouldn't point to something called snake-oil. Nah, if you replace the snakeoil certificate by a real one, it's not snake-oil anymore, of course. If you don't want to use a snakeoil certificate, you'll have to provide a real one anyway, best would be if it was certified by a commonly accepted CA. Regards, Joey -- Long noun chains don't automatically imply security. -- Bruce Schneier Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
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? I believe that this is a good idea, however, I would like to propose a slightly different approach. At the moment, it seems that all applications use their own certificates and maybe also create them upon installation or rather configuration. It may be useful to have a certificate for each service, but it may also be useful to have one certificate for all services. This may be discussible but needs to be decided by the local admin anyway. Hence, we should try to make both ways easily implementable, especially if the system is to be reviewed or redesigned. Hence, I propose to stay with virtual per-service certificates, but to link them to the common snakeoil certificate from ssl-certificates during configuration and only if there is no other setting. For example: Dovecot uses /etc/ssl/certs/dovecot.pem. This is a symbolic link to /etc/ssl/certs/ssl-cert-snakeoil.pem if the above file or link does not exist during configuration of dovecot. That way, the admin can easily replace the symlink with a real certificate if they want per-service certificates. If, however, they want to have one real certificate for everything, they can replace the snakeoil certificate like Martin Pitt proposed. I would like to see some coordination between maintainers of packages that use or create such certificates. It'll take a while to implement this anyway, so if only a few packages start and others follow later, that'd be an improvement anyway. Regards, Joey -- Open source is important from a technical angle. -- Linus Torvalds Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Do den 20. Jul 2006 um 11:24 schrieb Martin Schulze: [one cert for all services] I believe that this is a good idea, however, I would like to propose a slightly different approach. At the moment, it seems that all applications use their own certificates and maybe also create them upon installation or rather configuration. I like this idea mentioned above. Isn't it easy to ask the admin in debconf for every service if he want separate certs or all linked together? Hence, I propose to stay with virtual per-service certificates, but to link them to the common snakeoil certificate from ssl-certificates during configuration and only if there is no other setting. That would be another way. Regards Klaus Ethgen - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen [EMAIL PROTECTED] Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iQEVAwUBRL+ftp+OKpjRpO3lAQJtJgf+M4e/D970JQZDTbUg00z4PTBVD0ts7Hex XffYVpJt+dhQzXh2ljO/7vuqH2wxWvSuxevix4QSpAeJl9RpFceFsgMerpT7rqIv lPzo+JljGeWQb02kNnRZE8aRhNjsesEBr6RIDwRnB8+zKgxzTKOqdH0pvi3iTkUB 39fBJ1v3NcYxc7DDwRWcG1Aw9I6yJgsMGexiQs0w/OZ9yY3aE8HQuyiaPhy7UnJr FvJyO2Ddv4AOMXxVIf2PRpcGsbKf0y0mX30mVVL3FzW+qPPC8PBeM/iAnex+oZGL wrWsdvzk3L93KMaS2EdgwW+k/0AnwPq6XNj+0XoWZJIuljHLr9xPJw== =a/xx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
(please copy debian-devel, feel free to bounce my mail there after you've done so, for others to be able to comment as well). Klaus Ethgen wrote: Am Do den 20. Jul 2006 um 11:24 schrieb Martin Schulze: [one cert for all services] I believe that this is a good idea, however, I would like to propose a slightly different approach. At the moment, it seems that all applications use their own certificates and maybe also create them upon installation or rather configuration. I like this idea mentioned above. Isn't it easy to ask the admin in debconf for every service if he want separate certs or all linked together? No! Please don't introduce more questions that are not required for packages to work properly. Debconf is not a general configuration utility that should subsume all possible configurations. Instead it should only ask what is required for the package to work properly in a default environment. If an admin wants to use different certs, they should be able to do so easily, but it's not acceptable to ask everybodo whether to use shared or singular certificates, or to create a cert, or to install an already created and certified one, or, or, or... Regards, Joey -- Open source is important from a technical angle. -- Linus Torvalds Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
On Thu, Jul 20, 2006 at 11:24:34AM +0200, Martin Schulze wrote: For example: Dovecot uses /etc/ssl/certs/dovecot.pem. This is a symbolic link to /etc/ssl/certs/ssl-cert-snakeoil.pem if the above file or link does not exist during configuration of dovecot. That way, the admin can easily replace the symlink with a real certificate if they want per-service certificates. If, however, they want to have one real certificate for everything, they can replace the snakeoil certificate like Martin Pitt proposed. Sorry if I misunderstand something, but is it okay to call it snakeoil if it is real certificate? I like to say that the symbolic links for per-service certificate shouldn't point to something called snake-oil. Just my opinion. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
On Thu, Jul 20, 2006 at 11:24:34AM +0200, Martin Schulze wrote: Hence, I propose to stay with virtual per-service certificates, but to link them to the common snakeoil certificate from ssl-certificates during configuration and only if there is no other setting. For example: Dovecot uses /etc/ssl/certs/dovecot.pem. This is a symbolic link to /etc/ssl/certs/ssl-cert-snakeoil.pem if the above file or link does not exist during configuration of dovecot. That way, the admin can easily replace the symlink with a real certificate if they want per-service certificates. If, however, they want to have one real certificate for everything, they can replace the snakeoil certificate like Martin Pitt proposed. This would be a great improvement. I'd suggest one more level of symlinks. Have the individual services symlink to /etc/ssl/certs/ssl-cert-site.pem, which is then symlinked to ssl-cert-snakeoil.pem. When/if the local admin installs an actual site-wide certificate, updating the one ssl-cert-site.pem symlink will update all of the individual services using the the site cert, and the snakeoil cert is still available if you ever need to fail back to it. tony -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
James Westby schrieb: On (03/07/06 23:34), Petter Reinholdtsen wrote: [Jaldhar H. Vyas] 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? Yes, it is a good idea to make the SSL certificate handling in Debian packages more consistent. In Debian-Edu, we install and automatically configure several services with SSL certiciates, like imap, ldap and webmin, and it is a pain to handle all the ways SSL-certificates are generated. :) So, as this proposal seemed to provoke a response that was somewhere between non-caring and enthusiastic I thought I would look in to the possibility of doing this. An estimate of the pacakages that generate a certificate in postinst (lets hope there are none that include them in the package) I tried: $ grep-available -FDepends openssl -sPackage -n | sort apache-ssl apache2-common ca-certificates courier-imap-ssl courier-ssl dovecot-common dsniff ejabberd exim-tls freeswan ftpd-ssl httping ipopd libapache-mod-ssl libmultisync-plugin-syncml nessusd openoffice.org-core partimage-server python-pyopenssl ssl-cert ssleay sslwrap stone-ssl stunnel stunnel4 telnetd-ssl tinyca ultrapossum-tls usermin uw-imapd webmin Well there are a number of packages out there that can use X509 Certs but don't do so now as per default for example lighttpd. racoon seems to be missing as well but it doesn't look to be in good shape (in testing) anyway. I'd like to help but I'm not a DD. greets Uwe -- http://www.x-tec.de http://www.highspeed-firewall.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
On Tue, Jul 04, 2006 at 02:38:30PM +0200, Uwe A. P. Würdinger wrote: James Westby schrieb: An estimate of the pacakages that generate a certificate in postinst (lets hope there are none that include them in the package) I tried: $ grep-available -FDepends openssl -sPackage -n | sort Well there are a number of packages out there that can use X509 Certs but don't do so now as per default for example lighttpd. Toss pound into the list as well. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
[Jaldhar H. Vyas] 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? Yes, it is a good idea to make the SSL certificate handling in Debian packages more consistent. In Debian-Edu, we install and automatically configure several services with SSL certiciates, like imap, ldap and webmin, and it is a pain to handle all the ways SSL-certificates are generated. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
On (03/07/06 23:34), Petter Reinholdtsen wrote: [Jaldhar H. Vyas] 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? Yes, it is a good idea to make the SSL certificate handling in Debian packages more consistent. In Debian-Edu, we install and automatically configure several services with SSL certiciates, like imap, ldap and webmin, and it is a pain to handle all the ways SSL-certificates are generated. :) So, as this proposal seemed to provoke a response that was somewhere between non-caring and enthusiastic I thought I would look in to the possibility of doing this. An estimate of the pacakages that generate a certificate in postinst (lets hope there are none that include them in the package) I tried: $ grep-available -FDepends openssl -sPackage -n | sort apache-ssl apache2-common ca-certificates courier-imap-ssl courier-ssl dovecot-common dsniff ejabberd exim-tls freeswan ftpd-ssl httping ipopd libapache-mod-ssl libmultisync-plugin-syncml nessusd openoffice.org-core partimage-server python-pyopenssl ssl-cert ssleay sslwrap stone-ssl stunnel stunnel4 telnetd-ssl tinyca ultrapossum-tls usermin uw-imapd webmin which is a reasonable number (especially as some of these will be false-posistives). So then to see how ssl-cert is actually used I downloaded the source of apache2 and looked in debian/apache2-common.postinst where I found # Make self-signed certificate #if [ ! -f /etc/apache2/ssl/apache.pem ] #then #/usr/sbin/make-ssl-cert /usr/share/ssl-cert/ssleay.cnf #/etc/apache2/ssl/apache.pem #fi So looking in the changelog.debian I found the following apache2 (2.0.48-8) unstable; urgency=low * Disable ssl-cert until it sucks less. related to 230791 (closes: #231726) -- Thom May [EMAIL PROTECTED] Mon, 2 Feb 2004 12:47:10 + (that is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=230791 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=231726, http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ssl-cert is also quite enlightening) So, it seems the only packages in Debian that use ssl-cert don't actually at the moment. So it seems like ssl-cert needs some work before it can be used by more packages. The maintainers of ssl-cert are the apache maintainers themselves, so it doesn't look like they'll be sorting it out soon. I am willing to work a bit on getting it in to shape, does anyone want to volunteer to help out and then create patches for all the necessary packages? James -- James Westby [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
Jaldhar == Jaldhar H Vyas [EMAIL PROTECTED] writes: 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. Jaldhar Is this is a good idea for Debian? I think it is but it Jaldhar doesn't make sense to switch dovecot over unless all the Jaldhar other ssl-cert using packages also do it. Is this Jaldhar possible in the etch timeframe? I would really like it - I find it tedious configuring SSL certificates for each and every package, when they usually are the same... Having one copy reduces the chances of accidently storing a private key somewhere with inappropriate permissions. I don't expect such a system to implement virtual hosting without system administrator intervention, but a naming convention for the files that supports virtual hosts would be even better IMHO, e.g.: /etc/.../$hostname/... Where hostname is the name of the host identified by the certificate. That way adding/removing other certificates is easy. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
On Mon, 03 Jul 2006, Brian May wrote: I don't expect such a system to implement virtual hosting without system administrator intervention, but a naming convention for the files We must make this intervention easy, but other than that... that supports virtual hosts would be even better IMHO, e.g.: /etc/.../$hostname/... Where hostname is the name of the host identified by the certificate. That way adding/removing other certificates is easy. I very much doubt it would be easy to get the many APPs to expand that $hostname... IMHO we will be best served by going simple on this one and providing a boxed solution for single-certificate-per-host only. The much safer and saner per-service-certificate-per-host will require per-service configuration anyway... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
On (30/06/06 10:51), Jaldhar H. Vyas wrote: Following up to myself with a proper subject line. 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 hadn't seen the package before and it looks pretty decent. I think it would help get some consistency between all of the packages that have to create certs. It could perhaps even be wrapped up in to a debhelper tool if it is widespread enough. 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? I'm not sure, and maybe it's not the time to be trying to do this. Has anyone got a suggestion for a way to find the list of packages that generate a certificate in their postinst? That would help the decision. James -- James Westby [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
