| 2021-05-17 08:54:57 |
Dimitri John Ledkov |
bug |
|
|
added bug |
| 2021-05-17 08:55:14 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Bionic |
|
| 2021-05-17 08:55:14 |
Dimitri John Ledkov |
bug task added |
|
gnutls28 (Ubuntu Bionic) |
|
| 2021-05-17 08:55:14 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Trusty |
|
| 2021-05-17 08:55:14 |
Dimitri John Ledkov |
bug task added |
|
gnutls28 (Ubuntu Trusty) |
|
| 2021-05-17 08:55:14 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Xenial |
|
| 2021-05-17 08:55:14 |
Dimitri John Ledkov |
bug task added |
|
gnutls28 (Ubuntu Xenial) |
|
| 2021-05-17 08:55:14 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Precise |
|
| 2021-05-17 08:55:14 |
Dimitri John Ledkov |
bug task added |
|
gnutls28 (Ubuntu Precise) |
|
| 2021-05-17 08:55:29 |
Dimitri John Ledkov |
gnutls28 (Ubuntu): status |
New |
Fix Released |
|
| 2021-05-17 08:55:32 |
Dimitri John Ledkov |
information type |
Public |
Public Security |
|
| 2021-05-18 17:08:39 |
Dimitri John Ledkov |
description |
https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
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 |
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 |
|
| 2021-05-18 17:14:43 |
Dimitri John Ledkov |
description |
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 |
[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
[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 |
|
| 2021-05-18 17:25:25 |
Dimitri John Ledkov |
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
[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 |
[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
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 |
|
| 2021-05-18 17:27:01 |
Dimitri John Ledkov |
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
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 |
[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 |
|
| 2021-05-18 17:28:20 |
Dimitri John Ledkov |
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
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 |
[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 |
|
| 2021-05-19 21:29:40 |
Dimitri John Ledkov |
tags |
|
letsencrypt |
|
| 2021-05-19 21:41:20 |
Dimitri John Ledkov |
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 |
[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 |
|
| 2021-05-19 21:43:00 |
Dimitri John Ledkov |
tags |
letsencrypt |
letsencryptexpiry |
|
| 2021-05-20 05:34:34 |
Tom |
bug |
|
|
added subscriber Tom |
| 2021-07-14 23:21:07 |
Haw Loeung |
bug |
|
|
added subscriber The Canonical Sysadmins |
| 2021-08-26 00:29:57 |
Dimitri John Ledkov |
gnutls28 (Ubuntu Bionic): status |
New |
In Progress |
|
| 2021-08-26 00:30:05 |
Dimitri John Ledkov |
gnutls28 (Ubuntu Precise): status |
New |
Won't Fix |
|
| 2021-08-26 00:30:10 |
Dimitri John Ledkov |
gnutls28 (Ubuntu Bionic): assignee |
|
Dimitri John Ledkov (xnox) |
|
| 2021-08-26 00:35:59 |
Dimitri John Ledkov |
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 |
[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/+packages |
|
| 2021-08-27 12:38:53 |
Dimitri John Ledkov |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-08-27 12:40:08 |
Dimitri John Ledkov |
attachment added |
|
bionic_gnutls28_content.diff https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648/+attachment/5521238/+files/bionic_gnutls28_content.diff |
|
| 2021-08-27 13:51:46 |
Dimitri John Ledkov |
gnutls28 (Ubuntu Xenial): assignee |
|
Dimitri John Ledkov (xnox) |
|
| 2021-08-27 13:51:51 |
Dimitri John Ledkov |
gnutls28 (Ubuntu Xenial): status |
New |
In Progress |
|
| 2021-08-31 10:40:22 |
Dimitri John Ledkov |
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/+packages |
[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 availabel from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4663 |
|
| 2021-08-31 10:40:52 |
Dimitri John Ledkov |
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 availabel from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4663 |
[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 |
|
| 2021-08-31 10:41:37 |
Dimitri John Ledkov |
attachment added |
|
xenial_gnutls28_content.diff https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1928648/+attachment/5521862/+files/xenial_gnutls28_content.diff |
|
| 2021-08-31 11:18:00 |
Dimitri John Ledkov |
bug |
|
|
added subscriber Ubuntu Security Team |
| 2021-09-06 13:29:00 |
Launchpad Janitor |
gnutls28 (Ubuntu Trusty): status |
New |
Confirmed |
|
| 2021-09-06 13:29:03 |
Stefan Huehner |
bug |
|
|
added subscriber Stefan Huehner |
| 2021-09-08 07:36:21 |
Mauricio Roberto Peccorini Lindo |
bug |
|
|
added subscriber Mauricio Roberto Peccorini Lindo |
| 2021-09-14 22:10:22 |
Steve Langasek |
gnutls28 (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2021-09-14 22:10:25 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2021-09-14 22:10:34 |
Steve Langasek |
tags |
letsencryptexpiry |
letsencryptexpiry verification-needed verification-needed-bionic |
|
| 2021-09-14 22:17:18 |
Steve Langasek |
gnutls28 (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2021-09-14 22:17:27 |
Steve Langasek |
tags |
letsencryptexpiry verification-needed verification-needed-bionic |
letsencryptexpiry verification-needed verification-needed-bionic verification-needed-xenial |
|
| 2021-09-15 08:47:36 |
Dimitri John Ledkov |
tags |
letsencryptexpiry verification-needed verification-needed-bionic verification-needed-xenial |
letsencryptexpiry verification-done-xenial verification-needed verification-needed-bionic |
|
| 2021-09-15 09:03:37 |
Dimitri John Ledkov |
tags |
letsencryptexpiry verification-done-xenial verification-needed verification-needed-bionic |
letsencryptexpiry verification-done verification-done-bionic verification-done-xenial |
|
| 2021-09-15 15:10:16 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2021-09-15 15:10:14 |
Launchpad Janitor |
gnutls28 (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2021-09-21 06:50:40 |
Mathew Hodson |
gnutls28 (Ubuntu): importance |
Undecided |
High |
|
| 2021-09-21 06:50:43 |
Mathew Hodson |
gnutls28 (Ubuntu Precise): importance |
Undecided |
High |
|
| 2021-09-21 06:50:45 |
Mathew Hodson |
gnutls28 (Ubuntu Trusty): importance |
Undecided |
High |
|
| 2021-09-21 06:50:47 |
Mathew Hodson |
gnutls28 (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2021-09-21 06:50:49 |
Mathew Hodson |
gnutls28 (Ubuntu Bionic): importance |
Undecided |
High |
|
| 2021-09-22 00:04:50 |
Launchpad Janitor |
gnutls28 (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2021-09-30 12:36:04 |
Steve Beattie |
bug |
|
|
added subscriber Steve Beattie |
| 2021-10-01 19:45:16 |
Dimitri John Ledkov |
gnutls28 (Ubuntu Trusty): status |
Confirmed |
Won't Fix |
|
| 2021-10-01 19:45:20 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Focal |
|
| 2021-10-01 19:45:20 |
Dimitri John Ledkov |
bug task added |
|
gnutls28 (Ubuntu Focal) |
|
| 2021-10-05 11:53:13 |
Launchpad Janitor |
gnutls28 (Ubuntu Focal): status |
New |
Confirmed |
|
| 2021-10-06 08:21:49 |
Johan Smits |
gnutls28 (Ubuntu Focal): status |
Confirmed |
New |
|
