[Bug 1928989] Re: expiring trust anchor compatibility issue
Dimitri John Ledkov
1928989 at bugs.launchpad.net
Mon Jun 28 12:58:26 UTC 2021
** Description changed:
[Impact]
- * openssl fails to talk to letsencrypt website past September 2021,
+ * 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
+ * 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
+ * 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
+ * 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
+ * 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 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
** Description changed:
[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
+ 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
+ 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
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1928989
Title:
expiring trust anchor compatibility issue
Status in openssl package in Ubuntu:
Fix Released
Status in openssl source package in Trusty:
New
Status in openssl source package in Xenial:
New
Bug 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989/+subscriptions
More information about the foundations-bugs
mailing list