[Bug 1928989] Autopkgtest regression report (openssl/1.0.2g-1ubuntu4.20)

Sat Jul 31 07:26:44 UTC 2021

All autopkgtests for the newly accepted openssl (1.0.2g-1ubuntu4.20) for xenial have finished running.
The following regressions have been reported in tests triggered by the package:

psqlodbc/1:09.03.0300-1 (armhf)
ruby2.3/2.3.1-2~ubuntu16.04.16 (s390x)
python3.5/3.5.2-2ubuntu0~16.04.13 (i386, amd64, ppc64el, s390x, armhf, arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/xenial/update_excuses.html#openssl

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
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