l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver <m...@netris.org> 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 <andr...@enge.fr> 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
