gnutls28 in trusty no longer validates many valid certificate chains, such as

Bug #1722411 reported by Anders Kaseorg on 2017-10-09
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gnutls28 (Ubuntu)
Julian Andres Klode

Bug Description


Recently, due to some combination of the recent ca-certificate SRU and server certificate chain reconfigurations, the gnutls28 package in trusty was left unable to validate many valid certificate chains, such as that of

 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

The problem is that although GeoTrust Global CA is a trusted certificate, gnutls28 gives up after noting that Equifax Secure Certificate Authority is not. This bug was fixed upstream by these commits:

[Test Case]

One way to reproduce this is by building and running gnutls-cli:

$ apt-get build-dep gnutls28
$ apt-get source gnutls28
$ cd gnutls28-3.2.11
$ debian/rules build
$ ./src/gnutls-cli
Processed 118 CA certificate(s).
Resolving ''...
Connecting to '2607:f8b0:4009:811::200e:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `C=US,ST=California,L=Mountain View,O=Google Inc,CN=*', issuer `C=US,O=Google Inc,CN=Google Internet Authority G2', EC key 256 bits, signed using RSA-SHA256, activated `2017-09-26 11:09:35 UTC', expires `2017-12-19 10:59:00 UTC', SHA-1 fingerprint `a2a8d7ae1097865469dd5cf830896b930b704c8c'
 Public Key ID:
 Public key's random art:
  +--[ EC 256]----+
  |o .o. |
  |E . . . |
  | . . . o. . |
  | . = o o |
  | . B oS + |
  | . o =+o= . |
  | . oo . |
  | . . |
  | oo.++ |

- Certificate[1] info:
 - subject `C=US,O=Google Inc,CN=Google Internet Authority G2', issuer `C=US,O=GeoTrust Inc.,CN=GeoTrust Global CA', RSA key 2048 bits, signed using RSA-SHA256, activated `2017-05-22 11:32:37 UTC', expires `2018-12-31 23:59:59 UTC', SHA-1 fingerprint `a6120fc0b4664fad0b3b6ffd5f7a33e561ddb87d'
- Certificate[2] info:
 - subject `C=US,O=GeoTrust Inc.,CN=GeoTrust Global CA', issuer `C=US,O=Equifax,OU=Equifax Secure Certificate Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2002-05-21 04:00:00 UTC', expires `2018-08-21 04:00:00 UTC', SHA-1 fingerprint `7359755c6df9a0abc3060bce369564c8ec4542a3'
- Status: The certificate is NOT trusted. The certificate issuer is unknown.
*** Verifying server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.

(Note that the gnutls-cli binary in trusty’s gnutls-bin package comes from gnutls26, which seems to have already received the necessary updates, although it requires the ‘--x509cafile /etc/ssl/certs/ca-certificates.crt’ option.)

[Regression Potential]

Most GnuTLS-dependent packages in trusty use gnutls26 rather than gnutls28, so potential regressions, if any, would likely manifest in self-compiled binaries and PPA packages that were specifically compiled against gnutls28. (I noticed this bug in the first place because vlc from ppa:jonathonf/vlc became unable to play YouTube videos.)

Anders Kaseorg (andersk) wrote :

Here is a patch for trusty that backports the relevant parts of the three upstream commits fixing this bug.

Anders Kaseorg (andersk) on 2017-10-09
tags: added: patch
Jeremy Bicha (jbicha) on 2017-10-15
Changed in gnutls28 (Ubuntu):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnutls28 (Ubuntu Trusty):
status: New → Confirmed
Julian Andres Klode (juliank) wrote :

Looking at it. First patch looks OK, have to compare the other patch with the upstream changes.

Changed in gnutls28 (Ubuntu Trusty):
status: Confirmed → In Progress
assignee: nobody → Julian Andres Klode (juliank)
Julian Andres Klode (juliank) wrote :

Just to record my analysis of the debdiff: The changes are basically the same as the upstream commits, except for the PKCS#11 changes. This means that PKCS#11 certificates are still checked in full. I'm not sure where that would be used, but it is not a security problem (less is allowed than upstream, not more).

I have verified that xenial contains the same fixes by checking that _gnutls_check_if_same_key() exists there.

The changelog mentions trusty-updates, and does not close the bug report. I added (LP: #1722411)
as a final line and changed the distribution to trusty to match other uploads.

I'm building now, and will verify that the bug is fixed and upload afterwards.

Julian Andres Klode (juliank) wrote :

Built the package, run the command in the test, verified that it worked. popped the 2 patches, ran make again, verified that the command did not work. => tested OK


Changed in gnutls28 (Ubuntu Trusty):
importance: Undecided → Medium
Changed in gnutls28 (Ubuntu):
importance: Undecided → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers