[Bug 1928648] Re: expiring trust anchor compatibility issue

Tue May 18 17:25:25 UTC 2021

** Description changed:

  [Impact]

-  * gnutls28 fails to talk to letsencrypt website past September 2021,
+  * 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 
+  * 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

-  * Test connectivity to the expired-root-ca test website
- https://expired-root-ca-test.germancoding.com
+ 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
+ gnutls-cli --x509cafile=ca.pem https://expired-root-ca-test.germancoding.com/
+ 
+ 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
+  * 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.
+ 
+  * 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

** Description changed:

  [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

- 
+ 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
  gnutls-cli --x509cafile=ca.pem https://expired-root-ca-test.germancoding.com/

  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

** Description changed:

  [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
- gnutls-cli --x509cafile=ca.pem https://expired-root-ca-test.germancoding.com/
+ 
+ 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

-- 
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:
  New
Status in gnutls28 source package in Trusty:
  New
Status in gnutls28 source package in Xenial:
  New
Status in gnutls28 source package in Bionic:
  New

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

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