Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Key recovery with the following setup failed:
* keys generated using CRMFPopClient
* ECC CA/KRA with Thales HSM (v 12.30)
* KRA has default key wrapping params
How reproducible:
* set up ECC CA/KRA with Thales HSM v. 12.30
* keep default key wrapping setup with KRA
* generate csr. e.g.
CRMFPopClient -d . -p netscape -n "cn=my cfu 062019 ec, uid=mycfu" -q POP_SUCCESS -b kra.transport -a ec -w "AES/CBC/PKCS5Padding" -v -o crmf.req
in my test, I use CMCRequest to generate cmc request, then submit with HttpClient, sucessfully.
* Verify that the private key is archived (I just use kra agent page)
* proceed to do recovery of the key.
I used the default single agent recovery approval.
Actual results:
* journalctl -r shows:
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC < rv 0x000000D1 (CKR_TEMPLATE_INCONSISTENT)
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC < *phObject 0x00000000
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC Error: CKK_EC can only have CKA_SIGN or CKA_DERIVE not both.
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC > CKA_SENSITIVE: false
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC > CKA_PRIVATE: false
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC > CKA_TOKEN: false
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC > CKA_SIGN: true
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC > CKA_DERIVE: true
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: b67183fb 8f1a828d 38e0f42f 74342af1 6bf765d6 dc19f161 cf968926 93a6e142
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: pAtt->pValue= 32 bytes
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC > CKA_VALUE
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 06082a86 48ce3d03 0107
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: pAtt->pValue= 10 bytes
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC > CKA_EC_PARAMS
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 9385c5f2 a818387e 7a8c1a0d ec4bb3f5 a4742fbe
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: pAtt->pValue= 20 bytes
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC > CKA_ID
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC > CKA_KEY_TYPE: CKK_EC
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC > CKA_CLASS: CKO_PRIVATE_KEY
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC > hSession 0x000008CC
Jun 21 10:24:34 cfuhsm1.sjc.redhat.com server[27494]: 2019-06-21 10:24:34 [27494] t00c7ce62bc7f0000: pkcs11: 000008CC >> C_CreateObject
Version-Release number of selected component (if applicable):
pki core 10.5.17-1.el7_6
Expected results:
expect to succeed
Additional info:
Although I selected component to be pki-core, the issue could be anywhere from pki to jss to nss or the hsm.
It would help to identify when it was broken by finding out when QE last tested this scenario. I have already reached out to Geetika to get info.
just a reminder that under "How to reproduce", I have specified that
* KRA has default key wrapping params
Which means that the following should be false (that's the same as not being specified in a default setup)
kra.allowEncDecrypt.archival=false
kra.allowEncDecrypt.recovery=false
commit 06fdf41b2f5947f90d84b3fc32def4c8346c9601
Author: Christina Fu <cfu>
Date: Fri Nov 22 13:03:18 2019 -0500
Bug 1723008 - ECC Key recovery failure with CKR_TEMPLATE_INCONSISTENT
The current settings irt key wrapping parameters were depending on the
expection that the revised sw version for the nCipher HSM would be capable
of handling the key wrapping/unwrapping algorithm "AES KeyWrap/Padding";
As it turned out it did not completely do that.
This patch changes the default setting in the KRA CS.cfg as well as
CRMFPopClient to that of a supported wrapping algorithm: AES/CBC/PKCS5Padding
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1723008
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2020:1078