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 <ste...@huehner.org> > To: debian-...@lists.debian.org > Message-ID: <20210909153149.gf6...@huehner.biz> > > 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 > > > -----------------------------------------
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
