Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > On 03/19/2012 11:14 PM, Ben Hutchings wrote:
>> Personally, I think that it is a bad idea to treat the certificates in >> /etc/ssl/certs as automatically trusted. Even if packagers follow such >> a policy, system administrators likely will not read the policy and >> will not suspect that installing a certificate there has this effect. > If this is the consensus within the project, perhaps a bug should be filed > against the ca-certificates package then, since > /usr/share/doc/ca-certificates/README.Debian states: > ------------ > “update-ca-certificates” will then update “/etc/ssl/certs” which may be > used by the web browsers in Debian. It will also generate the hash > symlinks and generate a single-file version in > “/etc/ssl/certs/ca-certificates.crt”. > ------------ > and update-ca-certificates is run during postinst configure of the > ca-certificates package. Also, please be aware that the implicit trust of /etc/ssl/certs is probably embedded in LOTS and LOTS of local configuration of systems that use Debian, since the natural thing to do for any OpenSSL-derived code running on Debian is to point it to /etc/ssl/certs as the CAdir. At this point, I think the backward-compatibility demands are strong enough that if we're going to introduce a new directory structure, we would need to do it elsewhere and preserve /etc/ssl/certs as the CAdir for at least an extensive transitional period. > Is there any existing debian policy about X.509 certificates we should > be pursuing? What should the system administrator expect of > /etc/ssl/certs? Would more documentation someplace help? I don't know of an explicit policy outside of what the ca-certificates package has always done, but I'm sure that Stanford isn't the only site that makes *extensive* use of the ca-certificates system for web server certificates, including constructing intermediate certificate chains automatically using CAdir configuration and installing our own local CA certificates in /usr/local/share/ca-certificates precisely so that the ca-certificates system will link them into /etc/ssl/certs as trusted certificates and hash them for us. See also the ca-certificates-java package, which uses the same location to build a Java keystore and is used by various Java software. My recommendation would be that if one is generating a new special-purpose certificate that one doesn't want to be trusted, the right place for such a certificate would be in the /etc/<package> directory for the package. But I'm also somewhat dubious that any *substantial* harm would come of dropping the certificate in /etc/ssl/certs, even if that's not what it's for, since in this sort of scenario, if the private key is compromised, you probably have other problems more serious than someone using it to mint other certificates that other services on the same system might trust. I do agree that it's not precisely the correct thing to do from a formal security standpoint, though. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
