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.
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.
[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 /letsencrypt. org/certs/ staging/ letsencrypt- stg-root- dst.pem
https:/
* Test connectivity to the expired-root-ca test website /expired- root-ca- test.germancodi ng.com
https:/
setup:
apt install openssl /letsencrypt. org/certs/ staging/ letsencrypt- stg-root- x1.pem /letsencrypt. org/certs/ staging/ letsencrypt- stg-root- dst.pem stg-root- x1.pem letsencrypt- stg-root- dst.pem >> ca.pem
wget https:/
wget https:/
cat letsencrypt-
test case: root-ca- test.germancodi ng.com: 443 -servername expired- root-ca- test.germancodi ng.com -verify 1 -verifyCAfile ca.pem
openssl s_client -connect expired-
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 /community. letsencrypt. org/t/questions -re-openssl- client- compatibility- changes- for-let- s-encrypt- certificates/ 143817
https:/
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/ 0daccd4dc1f1ac6 2181738a91714f3 5472e50f3c
gnutls bug for this is https:/ /bugs.launchpad .net/ubuntu/ bionic/ +source/ gnutls28/ +bug/1928648