The issue has been recently resolved by the LTS Team, see LTS Advisory
DLA-2761-1 an DLA-2760-1. [1]
Thanks to the LTS Team!
Regards, Adrian.
[1]
https://www.debian.org/lts/security/
In der Nachricht vom Thursday, 9 September 2021 17:50:57 CEST schrieb Adrian
Zaugg:
> Dear List
>
> As far as I can tell, the reported issue on Debian-LTS List is also relevant
> for Devuan jessie, ascii and beowulf.
>
> Regards, Adrian.
>
>
> ---------- Forwarded Message ----------
>
> Subject: Upcoming compatibility problem of oldstable (and older) vs.
> certificates from Let's Encrypt
> Date: Thursday, 9 September 2021, 17:31:49 CEST
> From: Stefan Huehner <stefan@???>
> To: debian-lts@???
> Message-ID: <20210909153149.GF6114@???>
>
> Hello LTS Team,
>
> I want to raise a (rapidly) upcoming compatibility problem affecting older
> debian release when connecting via i.e. https:// to any system using SSL
> certificates from Let's Encrypt.
>
> Raising here as i didn't see any discussion in debian project.
>
> The problem:
> - Starting 2021-10-01
> - openssl < 1.1.0
> - gnutls < 3.6.14
>
> will fail to validate any Let's Encrypt SSL certificates (which did not do a
> per-certificate choice to avoid this).
>
> This article by the project has all the details:
> https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for
> -let-s-encrypt-certificates/143816
>
> In short:
> - They use a certificate chain containing a CA certificate expiring on
> 2021-10-01
> - While that path it not valid after that date, there is alternative path
> still being valid
> - However older version of some libraries do not even try alternative paths
> but give up on seeing the expired one
>
> In Ubuntu they are backporting the chances to avoid this problem in both
> openssl / gnutls:
> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989 (openssl)
> https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648
> (gnutls)
>
> Given the wide-spread use of Let's Encrypt it may make sense to consider
> doing that also on the debian side.
>
> Note that apt itself is using gnutls.
> So if people are using https:// to access some repos and the repo/mirror
> uses Let's Encrypt that could get much more annoying.
>
> Checking openssl / gnutls versions across releases:
> jessie libssl1.0.0 1.0.1t
> libgnutls-deb0-28 3.3.8
>
> stretch libssl1.0.2 1.0.2u
> libssl1.1 1.1.0l
> libgnutls30 3.5.8
>
> buster libssl1.0.2 1.0.2u
> libssl1.1 1.1.1d
> libtnutls30 3.6.7
>
> bullseye libssl1.1 1.1.1k
> libgnutls30 3.7.1
>
> Bug present in
> - openssl < 1.1.0
> - gnutls < 3.6.14
>
> Looks like:
> - bullseye is fine
> - But every older release seems to be affected
>
> Assuming there is interest this affects probably
> - LTS Team
> - ELTS if any of the sponsors is interested
> - 'normal' debian for old-stable ?
> I just wrote just here for the moment to not spam several teams.
>
> Let's Encrypt offers alternative chain avoiding this bug but breaking
> compatibility with old Android. That can server as a workaround for this
> issue on case by ase. But as this is on the 'other side' (each certificate)
> not really a global fix.
>
> Regards,
> Stefan Hühner
>
> p.s. Please CC me on replies, i am not on the list
>
>
> -----------------------------------------
::
Re: [DNG] Fwd: Upcoming compatibili…
