Re: Debian Policy about administrator X.509 certificate stores
Daniel Kahn Gillmor <dkg@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: