Hide Forgot
Description of problem: Key recovery with Key Identifiers fails when KRA is configured with lunaSA Version-Release number of selected component (if applicable): pki-base-10.3.3-10.el7.noarch pki-tools-10.3.3-10.el7.x86_64 pki-kra-10.3.3-10.el7.noarch How reproducible: Always Steps to Reproduce: 1. Generate a certificate request which archives the key 2. Approve the certificate request 3. From the Recovery section in KRA page select Key Identifiers and Show Key 4. Select Recover option from the results Actual results: Key recovery fails with the following message: "Problem processing your request" "certificate not found" Expected results: Key recovery should succeed. Additional info: Key recovery with certificate is working as expected. I am able to recover the key with a certificate.
Upstream ticket: https://fedorahosted.org/pki/ticket/2488
Per CS/DS meeting of 10/3/2016: 10.4 * dropped lunaSA from Summary * has a workaround -- requested in NEEDINFO to cfu
I can't seem to reproduce the issue. I was able to recover by keyid. Could you please provide debug log info?
FYI, the following key archival & retrieval procedure works without HSM: http://pki.fedoraproject.org/wiki/Certificate_Key_Archival
Asha, you dropped in the middle of our conversation, so here is what I'd like you and Sumedh to provide: For all cases, please provide more complete log session (so I have a better context) of a recovery much like: http://pastebin.test.redhat.com/423885 1. with LunaSA (this I understand is with FIPS disabled): a. the recovery by keyID b. the recovery by cert 2. with Thales (this I understand is with FIPS enabled): a. the recovery by keyID b. the recovery by cert thanks! Christina
Created attachment 1214147 [details] KRA key recovery on Firefox using key identifiers. CA and KRA installed with Thales hsm.
Created attachment 1214148 [details] Log messages for KRA key recovery on Firefox using certificate. CA and KRA installed with Thales hsm.
Created attachment 1214149 [details] Log messages for key_key_retrieve cli command using key identifiers. CA and KRA installed with Thales hsm.
Sumedh, please attach log files for the key recovery using key identifier, certificate, and kra_key_retrieve cli command when subsystems are configured with lunasa hsm.
Just some observation. I am now able to reproduce the originally reported issue on lunaSA with FF, where when recovering by keyid, it says "Certificate not found". Recovery by certificate still works, just as reported by Sumedh. Note that it is very different from the cli result from Thales, where issue with unwrapping happens. I have asked Endi to look into the cli command side of code path, as it seems to take a different path.
I should add that since the failures are very different, the cli one deserves to have its own bug (I recall there is one).
Thanks Christina! I am having setup problems with lunaSA. I'll provide the debug logs at the earliest.
Asha, this just occurred to me. For your tests in comment 10 and comment 11, I understand that the Thales HSM is in strict FIPS mode. My question is, did you turn on FIPS for nssdb? In Endi's test environment, I know his FIPS is enabled for nssdb, and I had to tweak the ciphers in server.xml for SSL to work in the case of pki cli (though it failed recovery in the end); FF also has issue connecting, which I have not put in too much time to investigate at the moment, but will soon. You did not raise any of the issues Endi ran into, hence my question about whether you enabled FIPS for nssdb or not. thanks, Christina
Update: I just resolved the FF SSL connection issue on Endi's FIPS-enabled machine. And I am able to confirm Asha's claim that from FF, key recovery is successful in this environment: Thales in strict (FIPS-142 level 3) mode and nssdb in FIPS (level 2) mode.
FYI, the key recovery issue using CLI in FIPS mode has been addressed as part of bug #1382066 (comment #13). The key recovery issue using key ID via Firefox originally reported in this bug is still valid.
Just for the records: answering the question I raised in Comment #16 above, about why is it that Asha did not ask for any assistance in getting SSL connection to work. During the investigation, after talking to her, I realized that she was following the older (RHCS8.1) CC document, where it instructed that when working with Thales HSM in FIPS mode, the SSL server certificate being replaced and placed in the nssdb instead. While it was true back then (I reported the issue to Thales then), I find this no longer to be needed (Thales must have fixed the issue for newer firmware). Anyway, the fact that Asha placed the ssl server cert in the nssdb was the reason why the she did not encounter any ssl issue.
For some reason I am not able to reproduce this issue. I tried recovering keys with key identifiers but it is working for me right now. I tried it with a Valid KRA Agent. I also tried with a Valid CA Agent as well and even that works. I am setting up fresh instances again and giving it another try.
Tested version: pki-kra-10.3.3-13.el7_3.noarch CA and KRA installed using Thales HSM. Key recovery using CLIs is generating a invalid p12 file. # pki -d /opt/rhqa_pki/admin_certs_db/ -c SECret.123 -p 31044 -n "PKI Administrator for idm.lab.eng.rdu.redhat.com" kra-key-retrieve --keyID 0x1 --output /opt/rhqa_pki/foo_user6_cert.p12 --passphrase SECret.890 # ll /opt/rhqa_pki/foo_user6_cert.p12 -rw-r--r--. 1 root root 1821 Nov 7 15:15 /opt/rhqa_pki/foo_user6_cert.p12 # pk12util -d /opt/rhqa_pki/admin_certs_db/ -i /opt/rhqa_pki/foo_user6_cert.p12 Enter Password or Pin for "NSS Certificate DB": Enter password for PKCS12 file: pk12util: PKCS12 decoding failed: SEC_ERROR_BAD_DER: security library: improperly formatted DER-encoded message. pk12util: PKCS12 decode not verified: SEC_ERROR_BAD_DER: security library: improperly formatted DER-encoded message.
Created attachment 1218249 [details] Key recovery cli kra-key-retrieve generates a invalid p12 file. KRA debug log attached.
A separate bug https://bugzilla.redhat.com/show_bug.cgi?id=1392616 has been filed for the issue in comment 21 and 22.
Per PKI Bug Council of 04/05/2017: CLOSING CURRENT RELEASE (QE RE-TEST) Since this bug has morphed throughout its existence, it was determined that it should be closed and re-tested by QE. QE will file new bugs if any issues still persist.