From: Mark H Weaver <mhw@netris.org>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: [PATCHES] profiles: Produce a single-file CA certificate bundle
Date: Tue, 03 Mar 2015 14:33:07 -0500 [thread overview]
Message-ID: <8761ahlvv0.fsf@netris.org> (raw)
In-Reply-To: <87a8zuntw7.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Tue, 03 Mar 2015 13:32:40 +0100")
ludo@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver <mhw@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 <andreas@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
next prev parent reply other threads:[~2015-03-03 19:32 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-02 23:11 [PATCH] gnu: gnutls: Configure location of system-wide trust store Mark H Weaver
2015-02-03 0:01 ` David Thompson
2015-02-03 20:53 ` Ludovic Courtès
2015-02-03 20:57 ` Marek Benc
2015-02-04 12:36 ` Andreas Enge
2015-02-04 12:42 ` Andreas Enge
2015-02-04 15:35 ` Mark H Weaver
2015-02-05 9:59 ` Andreas Enge
2015-02-08 13:36 ` Andreas Enge
2015-02-08 14:29 ` Andreas Enge
2015-02-08 15:24 ` Andreas Enge
2015-02-08 15:59 ` Mark H Weaver
2015-02-15 5:17 ` Mark H Weaver
2015-02-15 9:16 ` Andreas Enge
2015-02-15 16:59 ` Mark H Weaver
2015-02-23 21:34 ` Ludovic Courtès
2015-02-24 20:31 ` Mark H Weaver
2015-02-25 0:25 ` Andreas Enge
2015-03-02 22:12 ` /etc/ssl/certs and the certificate bundle Ludovic Courtès
2015-03-03 2:25 ` Mark H Weaver
2015-03-03 7:29 ` [PATCHES] profiles: Produce a single-file CA " Mark H Weaver
2015-03-03 8:27 ` Mark H Weaver
2015-03-03 12:23 ` Andreas Enge
2015-03-03 12:32 ` Ludovic Courtès
2015-03-03 19:33 ` Mark H Weaver [this message]
2015-03-03 20:04 ` Ludovic Courtès
2015-03-03 12:43 ` Ludovic Courtès
2015-03-03 12:55 ` Andreas Enge
2015-03-03 20:27 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8761ahlvv0.fsf@netris.org \
--to=mhw@netris.org \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.