Bug#481874: update-ca-certificates should not disable local certs
tags 481874 moreinfo thanks I'm just trying to reproduce this problem - can't make it! Lets assume: We add a local ca-cert to /usr/local/share/ca-certificates like told in update-ca-certificates(8) cp /usr/share/doc/openvpn/examples/sample-keys/ca.crt /usr/local/share/ca-certificates/testcert.crt and run update-ca-certificates afterwards Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Now testcert.crt appears in /etc/ssl/certs as link to /usr/local/share/ca-certificates/testcert.crt Now the upgrade case: Preparing to replace ca-certificates 20090814+nmu2 (using .../ca-certificates_20090814+nmu3_all.deb) ... Unpacking replacement ca-certificates ... Setting up ca-certificates (20090814+nmu3) ... (+nmu3 includes no changes affecting the reported behavior) Updating certificates in /etc/ssl/certs... 31 added, 3 removed; done. 31 are newly provided through +nmu3 and 3 got removed. Now, my testcert is still in /etc/ssl/cert but is now called testcert.pem as a .pem-extension is required for openssl's c_rehash. So i see the following action: Users want to place automatically there ca-certs into /etc/ssl/certs should only place the certs in /usr/local/share/ca-certificates and run update-ca-certificates once. Stefan -- Stefan Bauer - PGP: E80A 50D5 2D46 341C A887 F05D 5C81 5858 DCEF 8C34 plzk.de - Linux - because it works -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481874: update-ca-certificates should not disable local certs
Joey Schulze j...@infodrom.org writes: [...] In my case local certs are stored in /usr/local/share/ca-certificates/, Therefore ca-certificates.conf contains strincs such as ../../local/share/ca-certificates/infodrom-cacert.crt BTW, I see it as a problem per se. Perhaps this one deserves its own bug report, but given that update-ca-certificates(8) is sometimes useful just as a way to produce a certificates.crt file, why not to allow for a local certificates directory? Like: --- update-ca-certificates 2007-03-04 11:23:53 +0600 +++ update-ca-certificates 2009-09-01 01:11:52 +0700 @@ -66,11 +66,18 @@ sed -e '/^#/d' -e '/^!/d' $CERTSCONF | while read crt do if test $crt = ; then continue; fi - if ! test -f $CERTSDIR/$crt; then continue; fi - pem=$(basename $crt .crt).pem - ln -sf $CERTSDIR/$crt $pem - cat $CERTSDIR/$crt $bundletmp -done +## NB: local certificates are tried first +if [ -f $crt ]; then +f=$crt +elif [ -f $CERTSDIR/$crt ]; then +f=$CERTSDIR/$crt +else +continue +fi +pem=$(basename $f .crt).pem +ln -sf -- $f $pem +cat -- $f 7 +done 7 $bundletmp chmod 0644 $bundletmp mv -f $bundletmp $CERTBUNDLE This way, the local certificates are expected to be found in /etc/ssl/certs/ and can be activated in the usual manner: $ cat /etc/ca-certificates.conf ... ## local certificates ivan-shmakov-ca-2009-08-06.crt ivan-shmakov-ca-2009-08-06.2009-08-21-my-hw.crt ... $ which get disabled every time the package is updated. To fix this the attached script can be used to re-enable them again and re-call update-ca-certificates. [...] -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481874: update-ca-certificates should not disable local certs
This mail is intended for others who experience the same problem. Joey Schulze wrote: Package: ca-certificates Version: 20080514 After updating the spi-inc.org certificate that Debian uses my locally added certificates have been disabled in /etc/ca-certificates.conf. Naturally, this should not happen. The package should maintain a blacklist of certs to disable instead of disabling everything in that configuration file that doesn't come from the package (or whatever heuristics it currently uses). This problem still persists. However the package offers a means of handling this locally. One could add a script to the /etc/ca-certificates/update.d/ directory that re-adds the disabled certificates. In my case local certs are stored in /usr/local/share/ca-certificates/, Therefore ca-certificates.conf contains strincs such as ../../local/share/ca-certificates/infodrom-cacert.crt which get disabled every time the package is updated. To fix this the attached script can be used to re-enable them again and re-call update-ca-certificates. For local use the paths may require adjustments Regards, Joey -- Those who don't understand Unix are condemned to reinvent it, poorly. Please always Cc to me when replying to me on the lists. #! /bin/sh conf=/etc/ca-certificates.conf # ../../local/share/ca-certificates/infodrom-cacert.crt if grep -q '^!.*local/share/ca-certificates/.*\.crt' $conf then # echo Re-add local certificates sed -i 's,^!\(.*local/share/ca-certificates/.*\.crt\),\1,' $conf (sleep 20; update-ca-certificates /dev/null) fi
Bug#481874: update-ca-certificates should not disable local certs
On Sat, Feb 21, 2009 at 04:59:27PM +0100, Joey Schulze wrote: This problem still persists. However the package offers a means of handling this locally. One could add a script to the /etc/ca-certificates/update.d/ directory that re-adds the disabled certificates. The problem with that is that the hooks are just called if there are adds/removes of certs. The bundle is regenerated despite of this, though. I think maybe it should be run unconditionally and an update to do this be pushed through a point release. But I discovered this fact only shortly before the release. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Release Assistant `. `' xmpp:p...@0x539.de Stable Release Manager `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Bug#481874: update-ca-certificates should not disable local certs
Package: ca-certificates Version: 20080514 After updating the spi-inc.org certificate that Debian uses my locally added certificates have been disabled in /etc/ca-certificates.conf. Naturally, this should not happen. The package should maintain a blacklist of certs to disable instead of disabling everything in that configuration file that doesn't come from the package (or whatever heuristics it currently uses). Regards, Joey -- Never trust an operating system you don't have source for! 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]
