From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCHES] profiles: Produce a single-file CA certificate bundle Date: Tue, 03 Mar 2015 13:32:40 +0100 Message-ID: <87a8zuntw7.fsf@gnu.org> References: <87r3u7di49.fsf@netris.org> <20150204123652.GA21908@debian.eduroam.u-bordeaux.fr> <87wq3jah2w.fsf@netris.org> <20150215091632.GA9692@debian> <87sie79km0.fsf@netris.org> <87mw441fdp.fsf@gnu.org> <87sidvhx0t.fsf@netris.org> <87zj7v2gmf.fsf_-_@gnu.org> <87fv9medxv.fsf_-_@netris.org> <87bnkaeb8y.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46913) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSm0J-0000MA-W5 for guix-devel@gnu.org; Tue, 03 Mar 2015 07:32:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSm0C-0002X3-GH for guix-devel@gnu.org; Tue, 03 Mar 2015 07:32:47 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSm0C-0002Wz-Di for guix-devel@gnu.org; Tue, 03 Mar 2015 07:32:44 -0500 In-Reply-To: <87bnkaeb8y.fsf@netris.org> (Mark H. Weaver's message of "Tue, 03 Mar 2015 03:27:57 -0500") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Mark H Weaver Cc: guix-devel@gnu.org Mark H Weaver 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=E2=80= =99m not sure how we can do that. So far the approach has been to trust Mozilla=E2=80=99s bundle, which is apparently not such a great idea. But what can we trust here? > Several of the certs in /etc/ssl/certs have comments like this: > > # alias=3D"Bogus Global Trustee" > # trust=3D > # distrust=3DCKA_TRUST_CODE_SIGNING CKA_TRUST_EMAIL_PROTECTION CKA_TRUST_= SERVER_AUTH > # openssl-distrust=3DcodeSigning emailProtection serverAuth > > So it seems that the NSS certificate store may include known-bogus > certificates, perhaps to allow displaying a more severe security warning > than the common case of an unknown CA (e.g. self-signed certificates). > > We should find out whether these Bogus untrusted CA certificates are > present in Debian's /etc/ssl/certs, and whether they are present in its > ca-certificates.conf. We should also determine whether OpenSSL and > GnuTLS pay attention to those "distrust" comments (see above) in the > single-file certificate bundle, and whether they pay attention to them > in the smaller *.pem and hash-named files. Yes. If not, we may have to look for =E2=80=98distrust=E2=80=99 lines in o= ur own code and get rid of such certificates. > I will investigate later today, but if anyone is inspired to investigate > sooner and report their findings, feel free. It could be that 993300f6c > and/or e979e6dd523 should be reverted. That seems orthogonal to me. What we could do is to change =E2=80=98x509-certificates=E2=80=99 to default to an empty bundle, if NSS i= s deemed untrustworthy. Ludo=E2=80=99.