Re: Upcoming compatibility problem of oldstable (and older) vs. certificates from Let's Encrypt

[Sylvain Beucler <beuc@beuc.net>]

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.

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