Jessie iceweasel: This Connection is Untrusted

[Thomas Schmitt]

Hi,

i am confronted with an old Debian 8 "jessie" machine where since
(probably) yesterday the Iceweasel browser does not work any more
with many websites. E.g.

This Connection is Untrusted
...
lists.debian.org uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is unknown.
(Error code: sec_error_unknown_issuer)

Googling around (with Debian 10) gives me the idea that the installed
package ca-certificates is outdated.

It is currently not an option to upgrade the system to a newer Debian
version. I am even scared to do what i deduce from
https://serverfault.com/questions/891734/debian-wheezy-outdated-root-certificates
namely:

- add to /etc/apt/sources.list :
deb http://ftp.de.debian.org/debian-security/ jessie/updates main

- run:
apt-get update
apt-get install ca-certificates

Is this a good idea ? Will it do harm to the 6 year old system ?

---------------------------------------------------------------------------
If not a good idea:

Is there a known procedure to get and install the certificates manually ?
I see proposals to download .crt files and run
update-ca-certificates --fresh

Where would i get a current set of certificates ?

How do i identify the certificates which the browser does not accept ?
wget does not tell me the certificate name either.


Have a nice day :)

Thomas

[Andrew M.A. Cater]

Honestly - I'd suggest disconnecting the machine from the Internet until you
are able to upgrade it - it's far enough out of support that it's now ELTS.

https://deb.freexian.com/extended-lts/

I'd suggest that you consider immediate upgrade if you can - what is the
reason you cannot?

All the very best, as ever,

Andy Cater

[Thomas Schmitt]

Hi,

Andrew M.A. Cater wrote:
> Honestly - I'd suggest disconnecting the machine from the Internet until
> you are able to upgrade it - it's far enough out of support that it's now
> ELTS.

> I'd suggest that you consider immediate upgrade if you can

I know and am working long term on changing the situation.
Iceweasel is confined to no Javascript and the machine cannot (easily)
be reached from outside. Nevertheless it should be able to reach out
to some conservatively programmed web sites.

> - what is the reason you cannot?

Business, proprietary software, housebroken hardware, my big mouth that
GNU/Linux will not terminate service just because it is too old, ...

If the premium-but-old hardware breaks or if the browser itself breaks
with an important web site, then i have better arguments for a new system.
But a mere lack of https certificates is no strong reason. It just lets me
look stupid, currently.

So any cool sysadmin trick would be welcome, which does not change more
than necessary on this time-frozen system.

[to...@tuxteam.de]

On Fri, Oct 01, 2021 at 12:22:10PM +0200, Thomas Schmitt wrote:
> Hi,
>
> Andrew M.A. Cater wrote:
> > Honestly - I'd suggest disconnecting the machine from the Internet until
> > you are able to upgrade it - it's far enough out of support that it's now
> > ELTS.
> > I'd suggest that you consider immediate upgrade if you can

I assume Thomas knows pretty well what he's doing. He'd know much
better than me, in any case :-)

[...]

> So any cool sysadmin trick would be welcome, which does not change more
> than necessary on this time-frozen system.

If I've understood you correctly, you only have to do with a limited
set of sites. If this set is limited enough, you could perhaps look
up the root CAs certifying those (using a browser in a more modern
place), export them, and import them in your patient's browser.

It is excruciatingly manual (that's how browsers like their users,
but I disgress), but for a few sites (or just as a proof of concept,
to make sure a sprinkling of root CAs might solve your problem at
all) it might be useful.

> Have a nice day :)

Love your sig :)

Cheers
- t

[Thomas Schmitt]

Hi,

to...@tuxteam.de wrote:
> I assume Thomas knows pretty well what he's doing. He'd know much
> better than me, in any case :-)

Regrettably my sysadmin skills are severely underdeveloped.
I am qualified for the task only by being the guy who has Linux at home
and by having made fun of upgrade woes with other kinds of system.

> If I've understood you correctly, you only have to do with a limited
> set of sites.

I would prefer not to rely on an allow-list.

So i currently ponder how to transplant the certificates from a Debian 10
machine.
man update-ca-certificates talks of
/etc/ssl/certs
/etc/ca-certificates.conf
/usr/share/ca-certificates
In the latter i see on Debian 10:
./mozilla
with 126 .crt files.
The Debian 8 machine has 172 files in there.
The ca-certificates.conf files seem just to list those files on both
machines.

So a brute force attempt would be to rename the two directories and
the file to other names and to then copy the Debian 10 stuff to the
original names. The new /etc/ssl/certs would start empty and be
populated by update-ca-certificates(8).

Well, same old question: How bad an idea is this ?
What should i read before making such theories ?

Have a nice day :)

Thomas

[to...@tuxteam.de]

On Fri, Oct 01, 2021 at 01:20:01PM +0200, Thomas Schmitt wrote:

[...]

> So a brute force attempt would be to rename the two directories and
> the file to other names and to then copy the Debian 10 stuff to the
> original names. The new /etc/ssl/certs would start empty and be
> populated by update-ca-certificates(8).

Assuming Mozilla relies on those and doesn't have everything stashed
away locally. I don't even know where to start to find that out :-(

> Well, same old question: How bad an idea is this ?
> What should i read before making such theories ?

Actually, if you back up things, you don't have much to lose, have
you?

And then we'd have an answer to the above question, too ;-)

Here [1] is something about adding roots to a browser's little closed
world, in case the above fails.

Cheers & good luck

[1] https://wiki.mozilla.org/CA/AddRootToFirefox

- t

[Tobias Diekershoff]

Hey Thomas

On Fri, 01 Oct 2021 09:41:45 +0200
"Thomas Schmitt" <scdb...@gmx.net> wrote:

> i am confronted with an old Debian 8 "jessie" machine where since
> (probably) yesterday the Iceweasel browser does not work any more
> with many websites. E.g.

Are the untrusted certificates LetsEncrypt issued certs? Their old
R3 cert (signed by DST Root CA X3) expired Sept 29th (see e.g. [1]).
Maybe jessie has not gotten the new certs to trust LE certs now?

Greetings!
Tobias

1: https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190

--
Bōsī se sȳrī glaesās

PGP-ID ......... 0x25FE376FF17694A1

[David Wright]

On Fri 01 Oct 2021 at 13:20:01 (+0200), Thomas Schmitt wrote:

> I would prefer not to rely on an allow-list.
>
> So i currently ponder how to transplant the certificates from a Debian 10
> machine.
> man update-ca-certificates talks of
> /etc/ssl/certs
> /etc/ca-certificates.conf
> /usr/share/ca-certificates
> In the latter i see on Debian 10:
> ./mozilla
> with 126 .crt files.
> The Debian 8 machine has 172 files in there.
> The ca-certificates.conf files seem just to list those files on both
> machines.
>
> So a brute force attempt would be to rename the two directories and
> the file to other names and to then copy the Debian 10 stuff to the
> original names. The new /etc/ssl/certs would start empty and be
> populated by update-ca-certificates(8).
>
> Well, same old question: How bad an idea is this ?
> What should i read before making such theories ?

Looking at the Packages files for wheezy and stretch, the dependencies
haven't changed:

stretch
Package: ca-certificates
Version: 20200601~deb9u1
Installed-Size: 380
Maintainer: Michael Shuler <mic...@pbandjelly.org>
Architecture: all
Depends: openssl (>= 1.0.0), debconf (>= 0.5) | debconf-2.0

wheezy
Package: ca-certificates
Version: 20130119+deb7u1
Installed-Size: 432
Maintainer: Michael Shuler <mic...@pbandjelly.org>
Architecture: all
Depends: openssl (>= 1.0.0), debconf (>= 0.5) | debconf-2.0

So under the circumstances, having backed up the files in /etc
and /usr/share for ca-certificates and openssl, I would install
stretch's version manually, using the variant syntax:
apt ./ca-certificates_20200601~deb9u1_all.deb

Cheers,
David.

[Curt]

On 2021-10-01, Thomas Schmitt <scdb...@gmx.net> wrote:
> Hi,
>
> i am confronted with an old Debian 8 "jessie" machine where since
> (probably) yesterday the Iceweasel browser does not work any more
> with many websites. E.g.
>
> This Connection is Untrusted
> ...
> lists.debian.org uses an invalid security certificate.
> The certificate is not trusted because the issuer certificate is unknown.
> (Error code: sec_error_unknown_issuer)

They've talking about this here for the last few days.

I unfortunately have snipped your actual question but one workaround is
to install Firefox, which comes packed with it's own certificates (or
something of the sort).

Why you're browsing with an unsupported browser in an unsupported OS is
left as an exercise for yourself.

[Thomas Schmitt]

Hi,

as tomas predicted it can be done by handwork.

Tobias Diekershoff gave a good hint but i was not smart enough to make
use of it before i found out the clicky way.

The solution was to import to iceweasel the certificate file

/etc/ssl/certs/ISRG_Root_X1.pem

------------------------------------------------------------------------
Long story:

I replaced the directory trees
/etc/ssl/certs
/usr/share/ca-certificates
and the file
/etc/ca-certificates.conf
by their counterparts of Debian 10. Then i ran
update-ca-certificates
This did not help, even with newly started Iceweasel.

So i clicked my way through Preferences -> Advanced -> Cerificates to
button "View Certificates" which offers me an obscure list and a button
"Import". This gives me a file browser which i navigate to /etc/ssl/certs.
There are 128 .pem files from Debian 10.

To reduce the work i diffed the list of .pem files in both /etc/ssl/certs
and began to add those which are new in Debian 10: 49 files.
Many new ones did have no effect. But
/etc/ssl/certs/ISRG_Root_X1.pem
gives me back a lot of those sites which were unaccessible since yesterday.

I will have to wait for complaints to see if any of the previously working
sites still fails. A quick tour over the usual suspects finds none.
I nevertheless investied the clickwork to import the other new .pem files.
Just in case i forget what i did today.

Tobias Diekershoff wrote:
> Are the untrusted certificates LetsEncrypt issued certs? Their old
> R3 cert (signed by DST Root CA X3) expired Sept 29th (see e.g.

> https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiratio
> n-september-2021/149190

Looks like you are right.
In hindsight the hint to "ISRG Root X1" is in there. But i don't understand
their nomenclature. I looked for "DST*R3*.pem" but found no such file
in /etc/ssl/certs. (It's like with man pages: I understand their text only
when i finally found out by try and error.)

-------------------------------------------------------------------------
Remaining riddles:

How i would be supposed to find the name of the decisive certificate when
iceweasel refuses ?

Another riddle is why wget still does not work without option
--no-check-certificate
I found no hint in its man page about its default stash of certificates.
Will have to go on with research next week ...

[to...@tuxteam.de]

On Fri, Oct 01, 2021 at 06:32:21PM +0200, Thomas Schmitt wrote:
> Hi,
>
> as tomas predicted it can be done by handwork.
>
> Tobias Diekershoff gave a good hint but i was not smart enough to make
> use of it before i found out the clicky way.

Tobias is almost always spot-on :)

Cheers
- t

[mett]

On 2021年10月2日 1:32:21 JST, Thomas Schmitt <scdb...@gmx.net> wrote:

Hi,

as tomas predicted it can be done by handwork.

Tobias Diekershoff gave a good hint but i was not smart enough to make
use of it before i found out the clicky way.

The solution was to import to iceweasel the certificate file

  /etc/ssl/certs/ISRG_Root_X1.pem

Remaining riddles:

How i would be supposed to find the name of the decisive certificate when
iceweasel refuses ?

Another riddle is why wget still does not work without option
  --no-check-certificate
I found no hint in its man page about its default stash of certificates.
Will have to go on with research next week ...


Have a nice day :)

Thomas

Hi,

the final solution is:
-disable
the certs with an ! before
the cert name
(vi /etc/ca-certificates.conf:
!DST_Root_CA_X3.crt)
-then, rebuild the cert directory
(update-ca-certificates --fresh)
-then, restart your servers.

HTH