Re: [PATCHES] profiles: Produce a single-file CA certificate bundle

[Mark H Weaver]

address@hidden (Ludovic Courtès) writes:

> Mark H Weaver <address@hidden> skribis:
>
>> I think perhaps that we should be more selective in the certs we add to
>> ca-certificates.crt.  Debian has a configuration file
>> /etc/ca-certificates.conf, and only adds certificates that are
>> explicitly listed there to ca-certificates.crt.
>
> Based on what you write, I agree we should be more selective, but I’m
> not sure how we can do that.
>
> So far the approach has been to trust Mozilla’s bundle, which is
> apparently not such a great idea.  But what can we trust here?

The problem was not Mozilla's certificate bundle, it's how we were using
it.  We initially assumed that it would only contain trusted
certificates, but this is not the case.  They annotate the certificates
with trust metadata that we need to pay attention to.

Debian's ca-certificates package uses a variant of 'certdata2pem.py'
that only outputs trusted certificates.  The variant of that script that
we're using from Fedora outputs untrusted certificates as well, but
Fedora then takes care to install only the trusted ones.

The trust information is more than just a simple boolean.  There are
many distinct "trust types" that can be assigned, e.g. server-auth,
code-signing, email-protection, etc.

Fedora's system for handling CA certificates seems to be vastly more
sophisticated than Debian's.  All of the single-file bundles are
considered "legacy", and Fedora is able to produce multiple bundles
containing certs trusted for different purposes.

Doing this job properly will require more research, but it seems to me
that we should be looking to Fedora for guidance:

  http://pkgs.fedoraproject.org/cgit/ca-certificates.git
  http://pkgs.fedoraproject.org/cgit/openssl.git
  http://pkgs.fedoraproject.org/cgit/gnutls.git

Andreas Enge <address@hidden> writes:
> If we decide to remove certificates, this should not only be done in the
> aggregation phase into one file. They should be removed at the end of the
> nss-certs build, so that also the single certificate files will disappear.
> What is left over can be collected into one file as is done now.

Agreed.  For now, I've pushed my recently proposed commits (to support
certificate stores in profiles) along with changes to our 'nss-certs'
package to only install certificates that are annotated with a non-empty
"openssl-trust=" comment by our 'certdata2pem.py' (from Fedora).

> On Tue, Mar 03, 2015 at 01:43:38PM +0100, Ludovic Courtès wrote:
>> I just checked the source and OpenSSL itself does not use SSL_CERT_FILE
>> nor SSL_CERT_DIR at all.  Lynx does use SSL_CERT_FILE, but that’s really
>> in Lynx, not in libssl.  So I don’t think there should be a search path
>> specification for OpenSSL.  This is unfortunate, but it looks like we
>> can’t do much.
> 
> I just did a "strings" and "grep" on the binaries and libs. SSL_CERT_DIR
> appears in bin/c_rehash and lib/libcrypto.so, and SSL_CERT_FILE also appears
> in the latter.
> 
> In the source code,
> $ find -type f -exec grep -H SSL_CERT_DIR {} \;
> yields:
> 
> ./crypto/cryptlib.h:# define X509_CERT_DIR_EVP        "SSL_CERT_DIR"
[...]
> ./crypto/cryptlib.h:# define X509_CERT_FILE_EVP       "SSL_CERT_FILE"

Right.  I've forgotten the details, but about a year ago I looked
through the maze of OpenSSL code and determined that at least in some
cases, OpenSSL would honor those variables.  I guess the application can
specify whether or not to load the system trust store.

      Mark