On Thu, Sep 09, 2021 at 06:33:28PM +0200, Sylvain Beucler wrote: > Hello Stefan, > > Thanks for bringing this up, indeed it's worth fixing. > I can reproduce the issue on jessie and stretch (starting 2021-10-01), but > not on buster/oldstable. > > I'll further look into this issue.
Hi Sylvain, looking a tiny bit at changelog for gnutls buster it looks like the backport was already done :) 3.6.7-4+deb10u5 the _16 + _17 patches from the description sound like what i understand the fix is (explore alternative verification paths...) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961889 While not talking about Let's Encrypt specifically same case it seems. Assuming that confirms buster/oldtable should be just fine. I just noticed my previous mail was a bit wrong. buster apparently only contained libssl1.1 (and not also libssl1.0.2 additionally). Stefan > > Cheers! > Sylvain Beucler > Debian LTS Team > > On 09/09/2021 17:31, Stefan Huehner wrote: > >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
