GNU bug report logs - #46829
Let's Encrypt certificate store (le-certs) expired

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Leo Famulari <leo <at> famulari.name>
Cc: Christopher Baines <mail <at> cbaines.net>, 46829 <at> debbugs.gnu.org
Subject: bug#46829: `guix pull` uses incorrect certificate store
Date: Tue, 13 Apr 2021 11:29:58 +0200

Hi,

Leo Famulari <leo <at> famulari.name> skribis:

> On Sun, Apr 11, 2021 at 09:29:00PM -0400, Leo Famulari wrote:
>> I checked and, although there have been some changes upstream at Let's
>> Encrypt [0], our le-certs still works for contacting Savannah with TLS.
>
> I checked wrong; le-certs needs to be updated. I'm testing the update
> now...

So I think the issue is that, when ‘nss-certs’ is not installed, ‘guix
pull’ uses the LE certs, but these certificates expire quite frequently,
whereas if you have ‘nss-certs’ installed, there’s “always” a valid
authentication chain from the roots.

Indeed, running ‘guix pull’ in the 1.2.0 live VM image works (it has
‘nss-certs’ installed in /etc/ssl/certs).  Likewise, a Guix System 1.2.0
installation that includes ‘nss-certs’ (which is the default) is
unaffected.

For those who do not have ‘nss-certs’ installed, a workaround is to do
avoid HTTPS:

  guix pull --url=http://git.savannah.gnu.org/git/guix.git

This is fine because the ‘guix’ channel is authenticated anyway.

We could also add a ‘--no-check-certificates’ option to ‘guix pull’.
For that, Guile-Git needs to implement
‘git_transport_certificate_check_cb’ & co.  I started doing that but
it’s a bit of work (wrapping ‘struct git_cert’ is cumbersome) so I’m
willing to punt on it for now.

Thoughts?

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.