This works: $ openssl s_client -connect linux.intel.com:993 -verify 3 ... Certificate chain 0 s:/C=US/ST=CA/L=Santa Clara/O=Intel Corporation/OU=Intel Corporation/OU=Intel Corporation/CN=linux.intel.com 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 linux.intel.com -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 p11-kit-trust.so, not the original NSS libnssckbi.so. And the certificates are present: $ openssl s_client -connect linux.intel.com:993 -verify 3 < /dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 Identifier: X509v3 Subject Key Identifier: CF:3D:10:07:22:E5:37:22:56:59:07:21:63:91:AA:6A:96:31:20:37 X509v3 Authority Key Identifier: keyid:95:F5:A8:CD:2A:A4:B3:FF:1D:36:92:75:4A:82:93:92:7A:87:E7:DC $ 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 Flags: CKA_CERTIFICATE_CATEGORY=CA; CKA_TRUSTED; 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: 95:F5:A8:CD:2A:A4:B3:FF:1D:36:92:75:4A:82:93:92:7A:87:E7:DC -- X509v3 Authority Key Identifier: keyid:69:EB:30:91:1C:03:80:80:4E:11:15:88:46:A4:E2:41:9A:D3:69:1F ]$ 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 Flags: CKA_CERTIFICATE_CATEGORY=CA; CKA_TRUSTED; 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: 69:EB:30:91:1C:03:80:80:4E:11:15:88:46:A4:E2:41:9A:D3:69:1F -- X509v3 Authority Key Identifier: keyid:45:75:14:04:75:D6:BA:A6:FA:20:E8:5D:83:14:B4:E9:84:6D:37:48 $ 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 Flags: CKA_CERTIFICATE_CATEGORY=CA; CKA_TRUSTED; 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.
Hm, adding -R/usr/lib64/libnssckbi.so makes it work. It was trying to load libnssckbi.so 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...
So can we close or reassign this?
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/p11-kit-trust.so evolution with /usr/lib64/libnssckbi.so symlinked to pkcs11-spy.so, and only the offending IMAP account enabled.
Created attachment 1055818 [details] PKCS#11 spy output for tstclnt
Created attachment 1055819 [details] PKCS#11 spy output for evolution
It looks like Evolution isn't even *trying* to look up the issuer in the trust database. Should this be reassigned to NSS?
Agree.
Or Evolution, perhaps — firefox seems to validate this cert just fine, using the trust roots in p11-kit-trust.so (as symlinked from libnssckbi.so) 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.
Actually, for IMAP I think it's using GIO so that might be GnuTLS?
Not GnuTLS. If GTls were using GnuTLS to validate certificates, instead of reinventing the wheel for itself, then it would have been fine.
Please see bug 1284655. I guess that the recent fix to glib-networking (mentioned over there) might fix this bug, too.
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.
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.
[dwoodhou@shinybook ~]$ rpm -q glib-networking glib-networking-2.44.0-1.fc22.0.test.kaie.1.x86_64 [dwoodhou@shinybook ~]$ ./socket-client -v -T linux.intel.com:993 Connected to 10.23.219.25:993 local address: 10.252.29.60:55830 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.
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?
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.
*** This bug has been marked as a duplicate of bug 1286034 ***