[Bug 1928648] Re: expiring trust anchor compatibility issue

Wed Sep 8 16:01:01 UTC 2021

Hi Dmitry/Marc,
thanks for working on this and the related openssl bug, very appreciated trying avoiding the rapidly upcoming problem.

I think this gnutls could get be extra annoying (or very noisy for
support) as bionic is both still active LTS and also apt itself uses
gnutls backend. ESM maybe even worse (see end of this comment).

While Ubuntu repos itself seems to not have Let's Encrypt certificates a
couple of 3rd party repos have and some maybe quite common for
developers.

2 examples using Let's encrypt
a.) apt.postgresql.org
To get any still postgresql version for various ubuntu,debian releases
Note: They don't specifically use https:// url in their docs
b.) deb.nodesource.com
To get update node.js via an apt repo.
Their setup instructions specifically use https:// url's

While not having fix should not prevent apt from installing it (giving canonical repos seems to not be using Let's Encrypt) but:
- Lots of support question
- Not sure about unattended-upgrades, custom automation for package updates etc..

On top for ESM (i.e. xenial))
https://esm.ubuntu.com seems to be using Let's Encrypt
I did not check it specifically if it has the Android compatible chain triggering the openssl/gnutls bug or you are using the alternative chain.

If ESM is affected here that could be bigger issue as it prevents people
from installing the fix (if they don't get it before 2021-10-01)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gnutls28 in Ubuntu.
https://bugs.launchpad.net/bugs/1928648

Title:
  expiring trust anchor compatibility issue

Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls28 source package in Precise:
  Won't Fix
Status in gnutls28 source package in Trusty:
  Confirmed
Status in gnutls28 source package in Xenial:
  In Progress
Status in gnutls28 source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * gnutls28 fails to talk to letsencrypt website past September 2021,
  despite trusting the letsencrypt root certificate.

  [Test Plan]

   * Import staging cert equivalent to ISRG Root X1
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem

   * Import expired staging cert equivalen tto DST Root CA X3
  https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem

   * Test connectivity to the expired-root-ca test website
  https://expired-root-ca-test.germancoding.com

  setup:

  apt install wget gnutls-bin
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
  wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
  cat letsencrypt-stg-root-x1.pem letsencrypt-stg-root-dst.pem >> ca.pem

  test case:
  gnutls-cli --x509cafile=ca.pem expired-root-ca-test.germancoding.com

  bad result:
  - Status: The certificate is NOT trusted. The certificate chain uses expired certificate.
  *** PKI verification of server certificate failed...
  *** Fatal error: Error in the certificate.
  *** handshake has failed: Error in the certificate.

  good result:
  - Status: The certificate is trusted.
  - Description: (TLS1.3-X.509)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
  - Session ID: A8:2B:AF:85:54:64:3A:79:81:99:16:D4:6D:9A:FC:30:F1:EC:49:A4:09:A9:0C:31:37:38:C2:0E:73:C7:C9:04
  - Options: OCSP status request,
  - Handshake was completed

  Connection should be successful and trusted with correctly working
  gnutls client that can manage to ignore expired CA, and build a valid
  trust path using non-expired CA in the chain.

  [Where problems could occur]

   * Changes as to how the trust paths are built in TLS connection may
  result in introducing bugs (failure to connect to valid sites) and/or
  security vulnerabilities (connecting to invalid sites successfully).

  [Other Info]

   * Background info
   * The current chain from letsencrypt is expiring, they are adding a new chain, but also keeping the expiring one. This will result in connectivity issues when using old gnutls/openssl against websites using the default letsencrypt configuration after September 2021.

  https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
  https://community.letsencrypt.org/t/questions-re-openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143817

  Currently gnutls28 in bionic and earlier will not establish a
  connection, if any parts of the trust chain have expired, even though
  alternative non-expired chains are available.

  This has been fixed in GnuTLS 3.6.14, but probably should be
  backported to bionic and earlier if it was not already been done so.

  https://gitlab.com/gnutls/gnutls/-/issues/1008

  https://gitlab.com/gnutls/gnutls/-/merge_requests/1271

  Openssl bug report for this issue is
  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989

  Bionic packages available from https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/4661

  Xenial packages available from https://launchpad.net/~ci-train-ppa-
  service/+archive/ubuntu/4663

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648/+subscriptions