This is tenuously related to bug 1148889, but a separate issue. Take the same 'scsir-certchain.crt' file from that bug (also attached here), install it into /etc/pki/ca-trust/source/anchors and run update-ca-trust. See 'openconnect scsir.intel.com' work fine.
Created attachment 943419 [details] Full internal cert chain Now install this *full* cert chain in /etc/pki/ca-trust too (or instead). It contains the same certs as the other one, and *also* some other certs. Some of which have the same names as the certs you wanted. Now openconnect will fail to validate the server's certificate.
Created attachment 943420 [details] server specific cert chain
I fail to reproduce that either with gnutls-cli or openconnect. Could you attach the debugging output of gnutls-cli -d 99?
(note that I updated to gnutls-cli 3.3.8 from f21)
On F21: [root@dwoodhou-mobl5 anchors]# pwd /etc/pki/ca-trust/source/anchors [root@dwoodhou-mobl5 anchors]# md5sum * 7a7cbfa0dbc9075cc26b2d51fb272eac intel-internal.crt 0a713c69d8aaffaae9e9455a8949b45f scsir-certchain.crt [root@dwoodhou-mobl5 anchors]# openconnect scsir.intel.com POST https://scsir.intel.com/ Attempting to connect to server 213.190.153.55:443 SSL negotiation with scsir.intel.com Server certificate verify failed: signer not found Certificate from VPN server "scsir.intel.com" failed verification. Reason: signer not found Enter 'yes' to accept, 'no' to abort; anything else to view: ^CSSL connection failure: Error in the certificate. Failed to open HTTPS connection to scsir.intel.com Failed to obtain WebVPN cookie [root@dwoodhou-mobl5 anchors]# rm intel-internal.crt rm: remove regular file ‘intel-internal.crt’? y [root@dwoodhou-mobl5 anchors]# update-ca-trust [root@dwoodhou-mobl5 anchors]# openconnect scsir.intel.com POST https://scsir.intel.com/ Attempting to connect to server 213.190.153.55:443 SSL negotiation with scsir.intel.com Connected to HTTPS on scsir.intel.com Got HTTP response: HTTP/1.0 302 Temporary moved POST https://213.190.153.56/ Attempting to connect to server 213.190.153.56:443 SSL negotiation with 213.190.153.56 Connected to HTTPS on 213.190.153.56 Server requested SSL client certificate; none was configured POST https://213.190.153.56/ XML POST enabled Username:
Created attachment 943493 [details] debug output not working with all certs installed
Created attachment 943494 [details] debug output working with only required certs needed
As noted in private email, the issue here is that gnutls_pkcs11_get_raw_issuer() is returning *one* of the three certificates with the subject we're looking for. It doesn't happen to return the *right* one, so we find that the signature on the server's cert is invalid. The loop in find_cert_cb() needs to check the issuer right there and only return the *correct* cert.
Created attachment 944600 [details] typescript After some debugging from David we realized that CKA_ID doesn't necessarily match the SubjectKeyIdentifier in the trust modules for the certificates in question ("C=US,O=Intel Corporation,CN=Intel Intranet Basic Issuing CA 2B"). This is the reason of failure. PKCS #11 notes: "Note that with the version 3 extensions to X.509 certificates, the key identifier may be carried in the certificate. It is intended that the CKA_ID value be identical to the key identifier in such a certificate extension, although this will not be enforced by Cryptoki." So one would expect the CKA_ID to match the subjectKeyIdentifier in a trust module. Stef, is our conclusion correct? Shouldn't p11-kit's CKA_ID match the CA's subjectKeyIdentifier?
The will be a work-around in a later version of gnutls, but the issue is in the p11-kit trust module. Reassigning.
Part of the problem here lies with assupmtions about CKA_ID matching the X509v3 Subject Key Identifier. For two of the three certs named 'Intel Intranet Basic Issuing CA 2B', that assumption is true: Object 102: URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust;id=%9b%a7%c0%24%7e%fd%a7%fc%a7%be%82%19%3c%a1%51%97%37%97%fe%03;object=Intel%20Intranet%20Basic%20Issuing%20CA%202B;object-type=cert Type: X.509 Certificate Label: Intel Intranet Basic Issuing CA 2B ID: 9b:a7:c0:24:7e:fd:a7:fc:a7:be:82:19:3c:a1:51:97:37:97:fe:03 Object 103: URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust;id=%fc%1b%77%27%6c%ec%29%b4%de%5a%1b%2c%a9%88%ea%ae%7d%9e%98%be;object=Intel%20Intranet%20Basic%20Issuing%20CA%202B;object-type=cert Type: X.509 Certificate Label: Intel Intranet Basic Issuing CA 2B ID: fc:1b:77:27:6c:ec:29:b4:de:5a:1b:2c:a9:88:ea:ae:7d:9e:98:be For the third, however, it is not: Object 104: URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust;id=%0c%dd%bb%f6%2b%c4%05%40%8d%61%03%ff%07%30%bb%4e%65%e5%3e%b4;object=Intel%20Intranet%20Basic%20Issuing%20CA%202B;object-type=cert Type: X.509 Certificate Label: Intel Intranet Basic Issuing CA 2B ID: 0c:dd:bb:f6:2b:c4:05:40:8d:61:03:ff:07:30:bb:4e:65:e5:3e:b4 $ p11tool --export 'pkcs11:id=%0c%dd%bb%f6%2b%c4%05%40%8d%61%03%ff%07%30%bb%4e%65%e5%3e%b4;object-type=cert' | openssl x509 -text -noout | grep -A1 'Subject Key I' X509v3 Subject Key Identifier: 38:63:76:FA:B6:05:3A:A9:59:4F:4A:87:8D:A0:83:B7:7E:91:3A:0B We've fixed GnuTLS not to depend on the assumption that CKA_ID will match the Subject Key Identifier but it still prefers things that way as an optimisation. Why doesn't it match in this case?
(Note that there are cases where people have deliberately reissued CAs with the same key and Subject Key Identifier. Since I believe CKA_ID has to be unique, this means that we can't *rely* on them matching. But they certainly should have matched in this case.
I'm not sure that CKA_ID has to be unique. My reading of PKCS #11 2.30 (draft4), implies that it is not unique, as different DN with the same ID are explicitly allowed, and there is also the following text: "The CKA_ID field is intended to distinguish among multiple keys. In the case of public and private keys, this field assists in handling multiple keys held by the same subject;" So it would be apparent to me that two certificates that share the same key should also share the same CKA_ID.
(In reply to Nikos Mavrogiannopoulos from comment #13) > I'm not sure that CKA_ID has to be unique. My reading of PKCS #11 2.30 > (draft4), implies that it is not unique, as different DN with the same ID > are explicitly allowed, and there is also the following text: You're right. In previous versions of the spec it was alluded to that CKA_ID + CKA_CLASS should be unique ... but now things are pretty clear. > "The CKA_ID field is intended to distinguish among multiple keys. In the > case of public and private keys, this field assists in handling multiple > keys held by the same subject;" > > So it would be apparent to me that two certificates that share the same key > should also share the same CKA_ID. From the v2.40 spec: | It is intended that the CKA_ID value be identical to the key identifier in | such a certificate extension, although this will not be enforced by Cryptoki. David, could you attach the certificate file (or email it to me if sensitive) which is causing trouble here?
Created attachment 944645 [details] Use X509v3 Subject Key Identifier in p11_x509_calc_keyid() (In reply to Stef Walter from comment #14) > David, could you attach the certificate file (or email it to me if > sensitive) which is causing trouble here? It's in comment #1. It's the one which p11-kit currently assigns CKA_ID 0c:dd:bb:f6:2b:c4:05:40:8d:61:03:ff:07:30:bb:4e:65:e5:3e:b4 If you apply this patch, however, it correctly gets CKA_ID 38:63:76:fa:b6:05:3a:a9:59:4f:4a:87:8d:a0:83:b7:7e:91:3a:0b You'll probably want to fix the patch so that it works when the length of the Subject Key Identifier in the cert isn't precisely the same as the length of the ID you *would* have calculated for yourself.
David, Nikos, if either of you need this fix in RHEL 7.x, please open an appropriate bug there too. Otherwise I'll just target this to Fedora 21 and later.
David, could you try out the patch attached to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=84761 It's a bit more extensive, and fixes some assumptions that I had incorrectly made in code related to CKA_ID. If you end up needing a smaller patch, I can backport a simple one, based on your patch, to the stable branch.
That works for me. Tested in Fedora 21 without the workaround in GnuTLS, based on p11-kit commit c1dd399. Thanks for the prompt response.
Pushed patch to git master upstream.
p11-kit-0.22.1-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/p11-kit-0.22.1-1.fc21
Package p11-kit-0.22.1-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing p11-kit-0.22.1-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-12539/p11-kit-0.22.1-1.fc21 then log in and leave karma (feedback).
p11-kit-0.22.1-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.