| 2021-05-19 21:34:49 |
Dimitri John Ledkov |
bug |
|
|
added bug |
| 2021-05-19 21:35:05 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Trusty |
|
| 2021-05-19 21:35:05 |
Dimitri John Ledkov |
bug task added |
|
openssl (Ubuntu Trusty) |
|
| 2021-05-19 21:35:05 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Xenial |
|
| 2021-05-19 21:35:05 |
Dimitri John Ledkov |
bug task added |
|
openssl (Ubuntu Xenial) |
|
| 2021-05-19 21:35:13 |
Dimitri John Ledkov |
openssl (Ubuntu): status |
New |
Fix Released |
|
| 2021-05-19 21:40:49 |
Dimitri John Ledkov |
information type |
Public |
Public Security |
|
| 2021-05-19 21:43:05 |
Dimitri John Ledkov |
tags |
letsencrypt |
letsencryptexpiry |
|
| 2021-05-20 05:33:08 |
Tom |
bug |
|
|
added subscriber Tom |
| 2021-06-28 12:58:26 |
Dimitri John Ledkov |
description |
[Impact]
* openssl 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 openssl
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:
openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem
bad result:
connection failed
good result:
connection successful
Connection should be successful and trusted with correctly working openssl s_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 openssl in xenial 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 OpenSSL 1.1.0+ by setting X509_V_FLAG_TRUSTED_FIRST by default see https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c
gnutls bug for this is https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648 |
[Impact]
* openssl 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 openssl
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:
openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem
bad result:
connection failed
verify depth is 1
CONNECTED(00000003)
depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Doctored Durian Root CA X3
verify error:num=10:certificate has expired
notAfter=Jan 30 14:01:15 2021 GMT
140672978626200:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
good result:
connection successful
verify depth is 1
CONNECTED(00000003)
depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
verify return:1
depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
verify return:1
depth=0 CN = expired-root-ca-test.germancoding.com
verify return:1
---
Certificate chain
0 s:/CN=expired-root-ca-test.germancoding.com
i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend Pear X1
2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend Pear X1
i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored Durian Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
Connection should be successful and trusted with correctly working openssl s_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 openssl in xenial 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 OpenSSL 1.1.0+ by setting X509_V_FLAG_TRUSTED_FIRST by default see https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c
gnutls bug for this is https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648 |
|
| 2021-06-28 12:58:51 |
Dimitri John Ledkov |
description |
[Impact]
* openssl 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 openssl
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:
openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem
bad result:
connection failed
verify depth is 1
CONNECTED(00000003)
depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Doctored Durian Root CA X3
verify error:num=10:certificate has expired
notAfter=Jan 30 14:01:15 2021 GMT
140672978626200:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
good result:
connection successful
verify depth is 1
CONNECTED(00000003)
depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
verify return:1
depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
verify return:1
depth=0 CN = expired-root-ca-test.germancoding.com
verify return:1
---
Certificate chain
0 s:/CN=expired-root-ca-test.germancoding.com
i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend Pear X1
2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend Pear X1
i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored Durian Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
Connection should be successful and trusted with correctly working openssl s_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 openssl in xenial 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 OpenSSL 1.1.0+ by setting X509_V_FLAG_TRUSTED_FIRST by default see https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c
gnutls bug for this is https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648 |
[Impact]
* openssl 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 openssl ca-certificates wget
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:
openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem
bad result:
connection failed
verify depth is 1
CONNECTED(00000003)
depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Doctored Durian Root CA X3
verify error:num=10:certificate has expired
notAfter=Jan 30 14:01:15 2021 GMT
140672978626200:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
good result:
connection successful
verify depth is 1
CONNECTED(00000003)
depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
verify return:1
depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
verify return:1
depth=0 CN = expired-root-ca-test.germancoding.com
verify return:1
---
Certificate chain
0 s:/CN=expired-root-ca-test.germancoding.com
i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend Pear X1
2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend Pear X1
i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored Durian Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
Connection should be successful and trusted with correctly working openssl s_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 openssl in xenial 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 OpenSSL 1.1.0+ by setting X509_V_FLAG_TRUSTED_FIRST by default see https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c
gnutls bug for this is https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648 |
|
| 2021-06-28 13:15:49 |
Dimitri John Ledkov |
attachment added |
|
lp1928989.patch https://bugs.launchpad.net/ubuntu/xenial/+source/openssl/+bug/1928989/+attachment/5507665/+files/lp1928989.patch |
|
| 2021-07-09 15:43:40 |
Dimitri John Ledkov |
attachment added |
|
xenial_python3.5_content.diff https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989/+attachment/5510069/+files/xenial_python3.5_content.diff |
|
| 2021-07-09 15:44:16 |
Dimitri John Ledkov |
openssl (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2021-07-09 15:46:41 |
Dimitri John Ledkov |
description |
[Impact]
* openssl 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 openssl ca-certificates wget
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:
openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem
bad result:
connection failed
verify depth is 1
CONNECTED(00000003)
depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Doctored Durian Root CA X3
verify error:num=10:certificate has expired
notAfter=Jan 30 14:01:15 2021 GMT
140672978626200:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
good result:
connection successful
verify depth is 1
CONNECTED(00000003)
depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
verify return:1
depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
verify return:1
depth=0 CN = expired-root-ca-test.germancoding.com
verify return:1
---
Certificate chain
0 s:/CN=expired-root-ca-test.germancoding.com
i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend Pear X1
2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend Pear X1
i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored Durian Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
Connection should be successful and trusted with correctly working openssl s_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 openssl in xenial 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 OpenSSL 1.1.0+ by setting X509_V_FLAG_TRUSTED_FIRST by default see https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c
gnutls bug for this is https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648 |
[Impact]
* openssl 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 openssl ca-certificates wget
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:
openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem
bad result:
connection failed
verify depth is 1
CONNECTED(00000003)
depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Doctored Durian Root CA X3
verify error:num=10:certificate has expired
notAfter=Jan 30 14:01:15 2021 GMT
140672978626200:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
good result:
connection successful
verify depth is 1
CONNECTED(00000003)
depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
verify return:1
depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
verify return:1
depth=0 CN = expired-root-ca-test.germancoding.com
verify return:1
---
Certificate chain
0 s:/CN=expired-root-ca-test.germancoding.com
i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend Pear X1
2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend Pear X1
i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored Durian Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
Connection should be successful and trusted with correctly working openssl s_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 openssl in xenial 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 OpenSSL 1.1.0+ by setting X509_V_FLAG_TRUSTED_FIRST by default see https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c
Note only the new default flag is backported on its own. The other changes to more strongly verify additional auxiliary trust OIDs and key usage are not backported.
gnutls bug for this is https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648 |
|
| 2021-07-13 10:57:21 |
Dimitri John Ledkov |
description |
[Impact]
* openssl 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 openssl ca-certificates wget
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:
openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem
bad result:
connection failed
verify depth is 1
CONNECTED(00000003)
depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Doctored Durian Root CA X3
verify error:num=10:certificate has expired
notAfter=Jan 30 14:01:15 2021 GMT
140672978626200:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
good result:
connection successful
verify depth is 1
CONNECTED(00000003)
depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
verify return:1
depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
verify return:1
depth=0 CN = expired-root-ca-test.germancoding.com
verify return:1
---
Certificate chain
0 s:/CN=expired-root-ca-test.germancoding.com
i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend Pear X1
2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend Pear X1
i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored Durian Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
Connection should be successful and trusted with correctly working openssl s_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 openssl in xenial 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 OpenSSL 1.1.0+ by setting X509_V_FLAG_TRUSTED_FIRST by default see https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c
Note only the new default flag is backported on its own. The other changes to more strongly verify additional auxiliary trust OIDs and key usage are not backported.
gnutls bug for this is https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648 |
[Impact]
* openssl 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 openssl ca-certificates wget
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:
openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile ca.pem
bad result:
connection failed
verify depth is 1
CONNECTED(00000003)
depth=3 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Doctored Durian Root CA X3
verify error:num=10:certificate has expired
notAfter=Jan 30 14:01:15 2021 GMT
140672978626200:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:s3_clnt.c:1264:
good result:
connection successful
verify depth is 1
CONNECTED(00000003)
depth=2 C = US, O = (STAGING) Internet Security Research Group, CN = (STAGING) Pretend Pear X1
verify return:1
depth=1 C = US, O = (STAGING) Let's Encrypt, CN = (STAGING) Artificial Apricot R3
verify return:1
depth=0 CN = expired-root-ca-test.germancoding.com
verify return:1
---
Certificate chain
0 s:/CN=expired-root-ca-test.germancoding.com
i:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
1 s:/C=US/O=(STAGING) Let's Encrypt/CN=(STAGING) Artificial Apricot R3
i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend Pear X1
2 s:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Pretend Pear X1
i:/C=US/O=(STAGING) Internet Security Research Group/CN=(STAGING) Doctored Durian Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
Connection should be successful and trusted with correctly working openssl s_client that can manage to ignore expired CA, and build a valid trust path using non-expired CA in the chain.
[Testcase #2]
$ sudo apt install ca-certificates wget faketime
# Good connectivity
$ wget -O /dev/null https://canonical.com
--2021-07-13 11:54:20-- https://canonical.com/
Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 2001:67c:1360:8001::2c, 91.189.88.181, ...
Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 30933 (30K) [text/html]
Saving to: '/dev/null'
/dev/null 100%[============================>] 30.21K --.-KB/s in 0.001s
2021-07-13 11:54:20 (22.3 MB/s) - '/dev/null' saved [30933/30933]
# Jump to october to experience failure
$ faketime '2021-10-01' wget -O /dev/null https://canonical.com
--2021-10-01 00:00:00-- https://canonical.com/
Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2b, 2001:67c:1360:8001::2c, 91.189.88.181, ...
Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2b|:443... connected.
ERROR: cannot verify canonical.com's certificate, issued by 'CN=R3,O=Let\'s Encrypt,C=US':
Issued certificate has expired.
To connect to canonical.com insecurely, use `--no-check-certificate'.
# upgrade to new openssl, to see that connectivity is restored, even in october
$ dpkg-query -W libssl1.0.0
libssl1.0.0:amd64 1.0.2g-1ubuntu4.20
$ faketime '2021-10-01' wget -O /dev/null https://canonical.com
--2021-10-01 00:00:00-- https://canonical.com/
Resolving canonical.com (canonical.com)... 2001:67c:1360:8001::2c, 2001:67c:1360:8001::2b, 91.189.88.180, ...
Connecting to canonical.com (canonical.com)|2001:67c:1360:8001::2c|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 30933 (30K) [text/html]
Saving to: '/dev/null'
/dev/null 100%[============================>] 30.21K --.-KB/s in 0.001s
2021-10-01 00:00:00 (21.9 MB/s) - '/dev/null' saved [30933/30933]
[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 openssl in xenial 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 OpenSSL 1.1.0+ by setting X509_V_FLAG_TRUSTED_FIRST by default see https://github.com/openssl/openssl/commit/0daccd4dc1f1ac62181738a91714f35472e50f3c
Note only the new default flag is backported on its own. The other changes to more strongly verify additional auxiliary trust OIDs and key usage are not backported.
gnutls bug for this is https://bugs.launchpad.net/ubuntu/bionic/+source/gnutls28/+bug/1928648 |
|
| 2021-07-13 10:57:35 |
Dimitri John Ledkov |
openssl (Ubuntu Xenial): importance |
Undecided |
Critical |
|
| 2021-07-13 10:57:37 |
Dimitri John Ledkov |
openssl (Ubuntu Trusty): importance |
Undecided |
Critical |
|
| 2021-07-13 10:58:34 |
Dimitri John Ledkov |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-07-14 23:20:58 |
Haw Loeung |
bug |
|
|
added subscriber The Canonical Sysadmins |
| 2021-07-21 14:55:06 |
Steve Beattie |
openssl (Ubuntu Xenial): assignee |
|
Steve Beattie (sbeattie) |
|
| 2021-07-31 00:40:01 |
Steve Langasek |
openssl (Ubuntu Xenial): status |
Confirmed |
Fix Committed |
|
| 2021-07-31 00:40:04 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2021-07-31 00:40:09 |
Steve Langasek |
tags |
letsencryptexpiry |
letsencryptexpiry verification-needed verification-needed-xenial |
|
| 2021-08-12 16:17:14 |
Dimitri John Ledkov |
tags |
letsencryptexpiry verification-needed verification-needed-xenial |
letsencryptexpiry verification-done verification-done-xenial |
|
| 2021-08-18 20:59:44 |
Steve Beattie |
bug |
|
|
added subscriber Steve Beattie |
| 2021-08-19 17:01:52 |
Launchpad Janitor |
openssl (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2021-08-19 17:01:56 |
Steve Langasek |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2021-09-02 17:28:30 |
Stefan Huehner |
bug |
|
|
added subscriber Stefan Huehner |
| 2021-09-06 13:28:55 |
Launchpad Janitor |
openssl (Ubuntu Trusty): status |
New |
Confirmed |
|
| 2021-09-15 15:39:39 |
Sylvain Beucler |
attachment added |
|
debdiff.txt https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989/+attachment/5525428/+files/debdiff.txt |
|
