Re: [SOLVED] Re: Buster wget: The certificate of 'lists.debian.org' is not trusted
On Sat 02 Oct 2021 at 08:15:59 (+0200), tomas@tuxteam.de wrote:
> On Fri, Oct 01, 2021 at 03:18:22PM -0500, David Wright wrote:
>
> [...]
>
> > I have a buster system that was up-to-date from the last point-release
> > and kernel (2021-09-10 18:22:47).
> >
> > The only certificate expiration problem I have observed (and still
> > observe, having taken no action) is with apt-listbugs:
>
> [...]
>
> > However, my next thought was to temporarily move my
> > /etc/apt/apt.conf file, which contains just the one proxy
> > line pointing at apt-cacher-ng, with the result that
> > apt-listbugs was able to run without any problem.
>
> I understand correctly: using apt-cacher-ng somehow breaks
> certificate validation for apt-listbugs?
Well, let's put it like this. Nothing has failed during the
acquisition of the packages through apt-cacher-ng's caching
mechanism. I tested this by choosing a brand-new package to
install, and attempting to install it. Sure enough, the
download step succeeded, and the package appeared in the
cache pool.
However, the apt-listbugs step failed on account of an expired
certificate, just like the example quoted. man apt-listbugs
says that it reads /etc/apt/apt.conf:
$ cat /etc/apt/apt.conf
Acquire::http::Proxy "http://192.168.1.14:3142/";;
$
and temporarily removing that line allowed apt-listbugs to
succeed without provoking the error and ensuing dialogue.
> > I have no problem visiting bugs.debian.org with firefox
> > and lynx, so there's no urgency. I'm just happy that
> > two days ago I did a full install of bullseye on a
> > machine through my proxy and with listbugs turned on.
>
> That would be no surprise (provided I understood correctly
> above, that is): firefox and lynx don't proxy through
> apt-cacher-ng.
No, but look at the top of this thread:
"new certification problem, this time on buster.
"While looking why wget on Debian 8 does not work with lists.debian.org
i learn that it does not work on Debian 10 either:"
so in the interests of maximising the information in my post,
I checked that I didn't have that problem with either bug.d.o
or lists.d.o, or any other site.
I wanted to make this check, particular as my /etc/ssl/certs
contains a link to DST_Root_CA_X3.crt about which I know
nothing at all except that it's a certificate that had allegedly
just expired at midnight (see the older thread). The coincidence
in timing of this problem might be significant.
> > But it is odd that telling APT not to retrieve any bugs
> > should still say "Retrieving bug reports... Done".
>
> Proper messages are hard :)
You're right, but it would be fairly simple, I think, to turn
a two-way Fail/Done into a three-way Fail/Skipped/Done message,
only someone needs to point it out — like someone apparently
had already done for the message in the contemporaneous thread
https://lists.debian.org/debian-user/2021/10/msg00075.html
I know little about digital certificates except that:
. they cause trouble when they expire, and
. their keepers seem to forget that they're going to expire.
My ca-certificates_20200601~deb10u2_all.deb file is dated
Jan 29 2021 but the contents appear to be over a year old.
Does it contain the expired certificate? Do I rely on it?
Do I expect a new package soon? A routine upgrade, or one
caused by this specific problem? Bullseye's package is named
20210119, which just happens to be ten days before my file's
date. Does that mean my file is really just as up-to-date?
What does the string 20200601 actually mean?
Don't worry, those questions are just rhetorical, expressing
my ignorance.
Cheers,
David.
Reply to: