Bug 1142137

The certificate[2] sent by the server has issuer:
`C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority'

This certificate had its trust for SSL/TLS removed in version 2.1 of the CA list.

Because GnuTLS insists on finding a trust chain for the topmost intermediate CA certificate sent by the server, only, it fails to find a valid chain.

There are two solutions to this problem:

- enhance GnuTLS to be more flexible, and attempt to find an alternative
  trust chain for other included intermediates.
  This would work, because there is another trusted root CA cert in
  the global Mozilla CA list, that matches the issuer of cert[1].
  (This is what the NSS library does, and software using NSS
   still works fine with servers that are configured like this one.)

- reconfigure all servers on the Internet to no longer send any unnecessary
  intermediates.
  This is unrealistic, because there are too many servers and certs
  that are still valid,
  and because server operators might be worried about breaking some old
  legacy clients (software or devices) if they make that change.

Note: This fails with openssl too:

$ openssl s_client -verify 3  -connect na15.salesforce.com:443
...
    Verify return code: 27 (certificate not trusted)

It appears to fail with NSS tstclint too, even with the *old* ca-certificates package. But perhaps I'm doing something wrong:

$ /usr/lib64/nss/unsupported-tools/tstclnt  -h na15.salesforce.com -p 443
tstclnt: unable to open cert database: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format.
$ /usr/lib64/nss/unsupported-tools/tstclnt  -h na15.salesforce.com -p 443 -d sql:/etc/pki/nssdb
tstclnt: authentication of server cert failed: SEC_ERROR_UNKNOWN_ISSUER: Peer's Certificate issuer is not recognized.

(In reply to David Woodhouse from comment #2)
> It appears to fail with NSS tstclint too, even with the *old*
> ca-certificates package. But perhaps I'm doing something wrong:
> 
> $ /usr/lib64/nss/unsupported-tools/tstclnt  -h na15.salesforce.com -p 443
> tstclnt: unable to open cert database: SEC_ERROR_LEGACY_DATABASE: The
> certificate/key database is in an old, unsupported format.
> $ /usr/lib64/nss/unsupported-tools/tstclnt  -h na15.salesforce.com -p 443 -d
> sql:/etc/pki/nssdb
> tstclnt: authentication of server cert failed: SEC_ERROR_UNKNOWN_ISSUER:
> Peer's Certificate issuer is not recognized.

By default, NSS uses an empty trust list. Either the application must load a trust list module, or the database used must be configured to load it.

mkdir /tmp/nssdb
certutil -d sql:/tmp/nssdb -N --empty-password
modutil -dbdir sql:/tmp/nssdb -add roots \
        -libfile /etc/alternatives/libnssckbi.so.x86_64
tstclnt -d sql:/tmp/nssdb -p 443 -h na15.salesforce.com

works

I'm a little confused. A certificate bears a signature from a specific issuer, and it specifies the issuer. Usually using the X509v3 Authority Key Identifier. In the example at hand, it is as follows:

  X509v3 Authority Key Identifier: 
       keyid:0D:44:5C:16:53:44:C1:82:7E:1D:20:AB:25:F4:01:63:D8:BE:79:A5

The server also includes the certificate with ID 0d445c....be79a5. Which in turn is signed by a certificate with ID 7fd365....333133, etc.

At what point do we get to *choose* to use a different trust chain? I think I must be missing something.

If the server presents an *invalid* trust chain in its handshake, where one of the certs it presents is *not* the issuer of the previous cert in the chain, GnuTLS does truncate the chain at the brokenness and then attempt to find the trust root from there (I fixed this a year or two ago). But it's not clear to me what is expected here.

0: server cert
   signed by: ca-cert A

1: ca-cert A
   signed by: ca-cert B

2: ca-cert B
   signed by: ca-cert C

3: ca-cert B
   self-signed

If 2 and 3 are based on the same key pair, then the signature contained in 1 can be verified by either 2 or 3.

ca-cert C got removed from the pre-configured trust list.

The server sends 0+1+2

openssl and gnutls search for ca-cert C, fail, and give up.

NSS considers alternative 3, because the subject name of 3 matches the issuer name listed in 1.

If 3 contains a key that can be used to verify the signature in 1, verification succeeds.

If the authority key identifier is indeed based on the key, not on the whole issuer certificate, then the authority key ID should be identical for 2 and 3.

I'll attach the relevant certs 2 and 3 for this scenario.
Both certs contain identical subject key IDs, which means, they indeed both match the authority key ID of the subordinate cert 1.

Created attachment 938252 [details]
2

Created attachment 938253 [details]
3

Created attachment 938254 [details]
dump of 2

Created attachment 938255 [details]
dump of 3

Kai,
 There is no reason to play ping-pong with this bug. It is already reported in ca-certificates (#1134602). Removing such important CA certificates from the system trust list is a system wide change and you must follow the process in:
http://fedoraproject.org/wiki/Changes/Policy

Since you have not followed that changes policy I reassign it to the ca-certificates package. The reason to use the changes policy is so that we can coordinate and offer a workable system to users.


As to the point of your request, it is a wishlist item. There is no protocol requirement from an implementation to discover alternative paths. We can disagree on that, but don't put the users of Fedora in the middle by forcing that change on a stable release.

(In reply to Kai Engert (:kaie) from comment #1)

> There are two solutions to this problem:
> 
> - enhance GnuTLS to be more flexible, and attempt to find an alternative
>   trust chain for other included intermediates.
>   This would work, because there is another trusted root CA cert in
>   the global Mozilla CA list, that matches the issuer of cert[1].
>   (This is what the NSS library does, and software using NSS
>    still works fine with servers that are configured like this one.)
> 
> - reconfigure all servers on the Internet to no longer send any unnecessary
>   intermediates.
>   This is unrealistic, because there are too many servers and certs
>   that are still valid,
>   and because server operators might be worried about breaking some old
>   legacy clients (software or devices) if they make that change.

There is a third solution you forgot. Add the intermediate certificates issued by the CAs that are being removed to the trusted list.

(In reply to Nikos Mavrogiannopoulos from comment #11)
> 
> There is a third solution you forgot. Add the intermediate certificates
> issued by the CAs that are being removed to the trusted list.

It's futile to come up with that full set. Additionally, you'll lose the OCSP ability, if you no longer trust OCSP signatures of the CA cert that issued those intermediates. It's unclear which certificates are still good or which ones need to be revoked.

These difficulties can be avoided by finding the trust chain to the alternative issuer and ignoring the topmost intermediate in the chain.

(In reply to Kai Engert (:kaie) from comment #12)
> (In reply to Nikos Mavrogiannopoulos from comment #11)
> > 
> > There is a third solution you forgot. Add the intermediate certificates
> > issued by the CAs that are being removed to the trusted list.
> 
> It's futile to come up with that full set.

Not really, because for every intermediate that was removed a new anchor certificate  was introduced. So if we have X new anchors added to allow verification after the change we need the X intermediate certificates with the same key and DN as them.

> Additionally, you'll lose the
> OCSP ability, if you no longer trust OCSP signatures of the CA cert that
> issued those intermediates. It's unclear which certificates are still good
> or which ones need to be revoked.

OCSP will have to work anyway because as you said sites will still be using the old CA anchors and the CAs will have to provide OCSP responses for them.

I believe that issue is addressed in F21.