[Bug 1928989] Re: expiring trust anchor compatibility issue

Sat Jul 31 00:40:12 UTC 2021

Hello Dimitri, or anyone else affected,

Accepted openssl into xenial-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/openssl/1.0.2g-1ubuntu4.20 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
xenial to verification-done-xenial. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-xenial. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: openssl (Ubuntu Xenial)
       Status: Confirmed => Fix Committed

** Tags added: verification-needed verification-needed-xenial

-- 
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:
  Fix Committed

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.

  [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

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