Re: Upcoming compatibility problem of oldstable (and older) vs. certificates from Let's Encrypt
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
Reply to: