Is a SSL client required to try multiple certificate chains?

Question

Yesteday, 10 July 2019 I failed to access dict.tu-chemnitz.de with Epiphany (WebKit2, which is using GNUTLS) and mailed the administrator which fixed it quickly. Here is the access via GNUTLS:

$ gnutls-cli dict.tu-chemnitz.de
Processed 155 CA certificate(s).
Resolving 'dict.tu-chemnitz.de:443'...
Connecting to '134.109.133.9:443'...
- Certificate type: X.509
- Got a certificate list of 4 certificates.
- Certificate[0] info:
  - subject `CN=dict.tu-chemnitz.de,OU=Universitaetsrechenzentrum,O=Technische Universitaet Chemnitz,L=Chemnitz,ST=Sachsen,C=DE', issuer `CN=DFN-Verein Global Issuing CA,OU=DFN-PKI,O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.,C=DE', serial 0x1ddeea4d08db829c1f1b3603, RSA key 2048 bits, signed using RSA-SHA256, activated `2017-09-18 06:50:38 UTC', expires `2020-12-15 06:50:38 UTC', pin-sha256="HPAyb8xUhT23hfPUC+J6sxeVlW8e4K8N3JOGE2pZZH8="
    Public Key ID:
        sha1:f43cd7f782e17d07c98de23c71d613d834dde868
        sha256:1cf0326fcc54853db785f3d40be27ab31795956f1ee0af0ddc9386136a59647f
    Public Key PIN:
        pin-sha256:HPAyb8xUhT23hfPUC+J6sxeVlW8e4K8N3JOGE2pZZH8=

- Certificate[1] info:
  - subject `CN=DFN-Verein Global Issuing CA,OU=DFN-PKI,O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.,C=DE', issuer `CN=DFN-Verein Certification Authority 2,OU=DFN-PKI,O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.,C=DE', serial 0x1b63bad01e2c3d, RSA key 2048 bits, signed using RSA-SHA256, activated `2016-05-24 11:38:40 UTC', expires `2031-02-22 23:59:59 UTC', pin-sha256="2plWEFSbja5Tz0pERjlr4FL2fr0H4L48Rt0ZF3sKBEQ="
- Certificate[2] info:
  - subject `CN=DFN-Verein Certification Authority 2,OU=DFN-PKI,O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V.,C=DE', issuer `CN=T-TeleSec GlobalRoot Class 2,OU=T-Systems Trust Center,O=T-Systems Enterprise Services GmbH,C=DE', serial 0x00e30bd5f8af25d981, RSA key 2048 bits, signed using RSA-SHA256, activated `2016-02-22 13:38:22 UTC', expires `2031-02-22 23:59:59 UTC', pin-sha256="nKACHrGIK7Y2Rip247vWnOEfapF/v8H8rewd/Mzla8U="
- Certificate[3] info:
  - subject `CN=T-TeleSec GlobalRoot Class 2,OU=T-Systems Trust Center,O=T-Systems Enterprise Services GmbH,C=DE', issuer `CN=Deutsche Telekom Root CA 2,OU=T-TeleSec Trust Center,O=Deutsche Telekom AG,C=DE', serial 0x119c148cc1ac0e95, RSA key 2048 bits, signed using RSA-SHA256, activated `2016-04-25 09:01:39 UTC', expires `2019-07-09 23:59:59 UTC', pin-sha256="YQbA46CimYMYdRJ719PMGFmAPVEcrBHrbghA3RZvwQ4="
- Status: The certificate is NOT trusted. The certificate chain uses expired certificate. 
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.

As you can see, last certificated expired at 2019-07-09 23:59:59 UTC and therefore I wasn't able to access the page yesterday. DFN stands for Deutsches Forschungs Netzwerk, which translates to German Research Network.
I had not the time to wait until the scan of SSLLabs finished yesterday, which is - of course - now fine. I remember, that SSLShopper and a service of 1&1 also reported the problem. On the other hand, Chrome and Firefox accepted the certificate on my computer. I'm careful about Chrome and Firefox, which both cache intermediate certificates and silently reuse them when possible. Therefore I always test the validity of a certificate with Epiphany, GNUTLS or OpenSSL and external services.

It was explained to me, that the domain used a cross-certificate. Does a cross-certificate imply multiple certificate chains? Is a SSL client required to try out more than one chain?

PS: I recommend that dictionary, it's pretty good and comprehensive. There is also a desktop application. The admin is also friendly :)

Answer 1

I don't know if the client is actually required to check all possible chains but I know that at least OpenSSL by default does not check all possible chains.

In the past it followed the chain send by the server until the end (ignoring any self-signed at the end) and then checked if it finds a root certificate in the trust store to complete the chain. This caused various trouble with cross-certificates, see here for details.

Newer OpenSSL version (since 1.1.0) instead check at each step at the server provided chain if they have a locally trusted certificate which completes the chain it has so far.