Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1246492 - Server certificate not trusted when it should be.
Summary: Server certificate not trusted when it should be.
Status: CLOSED DUPLICATE of bug 1286034
Alias: None
Product: Fedora
Classification: Fedora
Component: glib-networking
Version: 22
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2015-07-24 12:57 UTC by David Woodhouse
Modified: 2015-11-27 10:03 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-11-27 10:03:35 UTC

Attachments (Terms of Use)
PKCS#11 spy output for tstclnt (deleted)
2015-07-24 15:34 UTC, David Woodhouse
no flags Details
PKCS#11 spy output for evolution (deleted)
2015-07-24 15:34 UTC, David Woodhouse
no flags Details

System ID Priority Status Summary Last Updated
GNOME Bugzilla 753260 None None None Never

Description David Woodhouse 2015-07-24 12:57:13 UTC
This works:
$ openssl s_client -connect -verify 3
Certificate chain
 0 s:/C=US/ST=CA/L=Santa Clara/O=Intel Corporation/OU=Intel Corporation/OU=Intel Corporation/
   i:/C=US/O=Intel Corporation/CN=Intel Intranet Basic Issuing CA 2A
 1 s:/C=US/O=Intel Corporation/CN=Intel Intranet Basic Issuing CA 2A
   i:/C=US/O=Intel Corporation/CN=Intel Intranet Basic Policy CA
 2 s:/C=US/O=Intel Corporation/CN=Intel Intranet Basic Policy CA
   i:/C=US/O=Intel Corporation/CN=Intel Root CA
 3 s:/C=US/O=Intel Corporation/CN=Intel Root CA
   i:/C=US/O=Intel Corporation/CN=Intel Root CA
    Verify return code: 0 (ok)
* OK Dovecot ready.

This doesn't:
$ mkdir /tmp/nssdb
$ certutil -d sql:/tmp/nssdb -N --empty-password
$ /usr/lib64/nss/unsupported-tools/tstclnt -h -p 993 -d sql:/tmp/nssdb -V ssl3: 
tstclnt: authentication of server cert failed: SEC_ERROR_UNKNOWN_ISSUER: Peer's Certificate issuer is not recognized.

I'm definitely using, not the original NSS And the certificates are present:

$ openssl s_client -connect -verify 3 < /dev/null 2>/dev/null  | openssl x509 -noout -text | grep -A1 Identifier:
            X509v3 Subject Key Identifier: 
            X509v3 Authority Key Identifier: 
$ p11tool --list-all  'pkcs11:model=p11-kit-trust;token=System%20Trust;id=%95%f5%a8%cd%2a%a4%b3%ff%1d%36%92%75%4a%82%93%92%7a%87%e7%dc;type=cert' 
Object 0:
	URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust;id=%95%f5%a8%cd%2a%a4%b3%ff%1d%36%92%75%4a%82%93%92%7a%87%e7%dc;object=Intel%20Intranet%20Basic%20Issuing%20CA%202A;type=cert
	Type: X.509 Certificate
	Label: Intel Intranet Basic Issuing CA 2A
	ID: 95:f5:a8:cd:2a:a4:b3:ff:1d:36:92:75:4a:82:93:92:7a:87:e7:dc
$ p11tool --export  'pkcs11:model=p11-kit-trust;token=System%20Trust;id=%95%f5%a8%cd%2a%a4%b3%ff%1d%36%92%75%4a%82%93%92%7a%87%e7%dc;type=cert' | openssl x509 -noout -text | grep -A1 Identifier:
            X509v3 Subject Key Identifier: 
            X509v3 Authority Key Identifier: 
]$ p11tool --list-all  'pkcs11:model=p11-kit-trust;token=System%20Trust;id=%69%eb%30%91%1c%03%80%80%4e%11%15%88%46%a4%e2%41%9a%d3%69%1f;type=cert' 
Object 0:
	URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust;id=%69%eb%30%91%1c%03%80%80%4e%11%15%88%46%a4%e2%41%9a%d3%69%1f;object=Intel%20Intranet%20Basic%20Policy%20CA;type=cert
	Type: X.509 Certificate
	Label: Intel Intranet Basic Policy CA
	ID: 69:eb:30:91:1c:03:80:80:4e:11:15:88:46:a4:e2:41:9a:d3:69:1f
$ p11tool --export  'pkcs11:model=p11-kit-trust;token=System%20Trust;id=%69%eb%30%91%1c%03%80%80%4e%11%15%88%46%a4%e2%41%9a%d3%69%1f;type=cert' | openssl x509 -noout -text | grep -A1 Identifier:
            X509v3 Subject Key Identifier: 
            X509v3 Authority Key Identifier: 
$ p11tool --list-all  'pkcs11:model=p11-kit-trust;token=System%20Trust;id=%45%75%14%04%75%d6%ba%a6%fa%20%e8%5d%83%14%b4%e9%84%6d%37%48;type=cert' 
Object 0:
	URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust;id=%45%75%14%04%75%d6%ba%a6%fa%20%e8%5d%83%14%b4%e9%84%6d%37%48;object=Intel%20Root%20CA;type=cert
	Type: X.509 Certificate
	Label: Intel Root CA
	ID: 45:75:14:04:75:d6:ba:a6:fa:20:e8:5d:83:14:b4:e9:84:6d:37:48

There were multiple CAs with the same name as those two intermediates. But I took those *out* of the system, since that has caused issues in t he past, and it didn't seem to make any difference.

Comment 1 David Woodhouse 2015-07-24 13:19:59 UTC
Hm, adding -R/usr/lib64/ makes it work. It was trying to load from the cert database directory otherwise (and failing if I didn't specify one).

That's annoying. The *actual* bug was that Evolution was failing to connect to this IMAP server, and tstclnt was just a convenient way of reproducing the failure with NSS...

Comment 2 Stef Walter 2015-07-24 14:13:49 UTC
So can we close or reassign this?

Comment 3 David Woodhouse 2015-07-24 14:41:39 UTC
Not sure. It might still end up being a p11-kit-trust problem.

I've asked the original reporter to provide the output of
PKCS11SPY=/usr/lib64/pkcs11/ evolution

with /usr/lib64/ symlinked to, and only the offending IMAP account enabled.

Comment 4 David Woodhouse 2015-07-24 15:34:09 UTC
Created attachment 1055818 [details]
PKCS#11 spy output for tstclnt

Comment 5 David Woodhouse 2015-07-24 15:34:44 UTC
Created attachment 1055819 [details]
PKCS#11 spy output for evolution

Comment 6 David Woodhouse 2015-07-24 15:35:52 UTC
It looks like Evolution isn't even *trying* to look up the issuer in the trust database. Should this be reassigned to NSS?

Comment 7 Stef Walter 2015-07-24 15:37:19 UTC

Comment 8 David Woodhouse 2015-07-24 16:11:04 UTC
Or Evolution, perhaps — firefox seems to validate this cert just fine, using the trust roots in (as symlinked from as it should.

But I can't see that Evolution is doing anything special and different, so we're probably need the NSS folks to *tell* us what it's doing wrong, if anything.

Note that the correct equivalent to Evolution's behaviour should be to invoke tstclnt with -dsql:/etc/pki/nssdb, rather than $HOME/.pki/nssdb. That makes no difference; it still works fine where Evolution fails.

Comment 9 David Woodhouse 2015-07-24 16:46:41 UTC
Actually, for IMAP I think it's using GIO so that might be GnuTLS?

Comment 10 David Woodhouse 2015-10-08 08:26:17 UTC
Not GnuTLS. If GTls were using GnuTLS to validate certificates, instead of reinventing the wheel for itself, then it would have been fine.

Comment 11 Kai Engert (:kaie) (inactive account) 2015-11-24 12:21:10 UTC
Please see bug 1284655.

I guess that the recent fix to glib-networking (mentioned over there) might fix this bug, too.

Comment 12 David Woodhouse 2015-11-24 14:20:58 UTC
It doesn't seem to. As noted in the upstream bug report (GNOME #753260), that patch papers over one of the symptoms of the real underlying bug, but it doesn't paper over *this* symptom.

Comment 13 David Woodhouse 2015-11-24 14:23:36 UTC
To clarify: the problem is that glib-network reimplements for itself the code which builds up a certificate chain. And — obviously — gets it wrong. One should never reimplement crypto code; that's what we have crypto libraries for, after all. If we just let the *library* do it, we'd be fine.

Bug 1284655 is one specific example of how we got it wrong, and we have papered over the problem by fixing that specific example. This bug covers another specific example. We could paper over this too, and we could keep patching things up until our reimplementation of the wheel is *not*, in fact, buggy.

The Right Thing to do is still to use the crypto library as $DEITY intended instead of doing it for ourselves.

Comment 14 David Woodhouse 2015-11-24 14:33:17 UTC
[dwoodhou@shinybook ~]$ rpm -q glib-networking
[dwoodhou@shinybook ~]$ ./socket-client -v -T
Connected to
local address:
Certificate would have been rejected ( expired ) but accepting anyway.

This appears to be the behaviour when the *wrong* intermediate CA (an expired one) is chosen as the issuer, instead of the one which is actually specified by the X509v3 Authority Key Identifier.

Comment 15 Kai Engert (:kaie) (inactive account) 2015-11-25 12:14:16 UTC
Your example host is on an Intranet.

Do you happen to know any server in the public that can be used to see your additional problem?

Comment 16 David Woodhouse 2015-11-25 14:10:50 UTC
You can easily generate such a scenario. Pick any server you want to test with. Look at its trust chain. Create a new certificate with the same *name* (but obviously different keys) as one of the certs in the chain. Add that new certificate to your trust database.

You might have to mess with the ordering to ensure that the 'wrong' one is picked first by the glib-networking code that shouldn't exist.

But obviously you shouldn't really need that, to fix this problem *properly* by ripping out the offending code and just using GnuTLS.

Comment 17 Nikos Mavrogiannopoulos 2015-11-27 10:03:35 UTC

*** This bug has been marked as a duplicate of bug 1286034 ***

Note You need to log in before you can comment on or make changes to this bug.