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.

Bug 1807371

Summary: KRA-HSM : Async and sync key recovery using kra agent web is failing
Product: Red Hat Enterprise Linux 8 Reporter: shalini <skhandel>
Component: jssAssignee: Alex Scheel <ascheel>
Status: CLOSED ERRATA QA Contact: PKI QE <bugzilla-pkiqe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.2CC: aakkiang, afarley, ascheel, cfu, dmoluguw, edewata, jmagne, lmiksik, mharmsen, rhcs-maint, skhandel
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: pki-core-10.6-8020020200326162741.c7c3114f Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 15:46:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1802014    
Attachments:
Description Flags
KRA debug logs for HSM ker recovery failure none

Description shalini 2020-02-26 08:34:30 UTC
Description of problem:
KRA : Async and sync key recovery using kra agent web is failing

Version-Release number of selected component (if applicable):

pki-kra-10.8.2-1.module+el8.2.0+5758+57f3761f.noarch
pki-ca-10.8.2-1.module+el8.2.0+5758+57f3761f.noarch


How reproducible:
Always

Steps to Reproduce:
1. Install CA and KRA instance on HSM machine.
2. Add kra.allowEncDecrypt.archive = true and kra.allowEncDecrypt.recovery = true in KRA's CS.cfg and restart kra server.
3. Generate a CRMF request "CRMFPopClient  -vvv    -d nssdb/     -p Secret.123  -a rsa -b transport.pem     -n "uid=testuser,o=example" "
4. Paste the generated request in Manual Administrator Certificate Enrollment profile in ee page- enrolment.
5. Submit a CRMF request and approve it from agent page.
6. Copy the generated base64 cert in  KRA key recovery web page.
7. Try recovery using async or sync method.

Actual results:
It fails with following exception:
    PKCS #12 Creation Failed java.lang.RuntimeException: Exception in EncryptedPrivateKeyInfo.createPBE: DES3/CBC/Pad cannot use a null parameter

Expected results:
Recovery should be success.

Additional info:
This behaviour is same for RSA and ECC installation on HSM.
Attached are the config files used for installation. And debug logs.

Comment 2 Christina Fu 2020-02-28 01:48:52 UTC
Here is a preliminary investigation observation report.
On Shalini's vm, she is running the following jss version
jss-4.6.2-2.module+el8.2.0+4573+c3c38c7b.x86_64
on which the PKCS #12 createPBE issue was observed consistently.

On my vm (F31), I was running the following jss version:
jss-4.6.0-1.20190715210734.d634b1ee.fc30.x86_64
Where I did not have any issue doing archival/recovery

Initially I thought maybe it's because she is using HSM and I was not.
However, after I upgraded my vm to the following, I am able to reproduce the issue on my nss-based instances:
jss-4.6.3-1.fc30.x86_64

Perhaps someone who made changes between the two versions might have a better guess on where things might have gone been inadvertently changed?

Comment 3 Asha Akkiangady 2020-02-28 16:35:07 UTC
Hi Shalini,
Looks like the step to restart CA after step #2 is missing. 
Could you please re-test with the latest builds of pki-kra-10.8.2-2.* and pki-ca-10.8.2-2.*?
thanks,
Asha

Comment 4 Alex Scheel 2020-02-28 19:23:02 UTC
This is a bug in JSS. Upstream pull request:

https://github.com/dogtagpki/jss/pull/416

Comment 10 shalini 2020-03-03 15:05:16 UTC
My observation on this.

By adding below in KRA's CS.cfg file and restarting CA and KRA service. key recovery works. 
kra.legacyPKCS12=false

Earlier I tried doing same, but it failed with following exception :
SEVERE: KRAService serviceRequest PKCS #12 Creation Failed org.mozilla.jss.crypto.TokenException: Failed to export EncryptedPrivateKeyInfo: (0) Unknown error

Following are the new builds on which i performed tests: 

pki-base-10.8.2-2.module+el8.2.0+5796+110ac6eb.noarch
pki-tools-10.8.2-2.module+el8.2.0+5796+110ac6eb.x86_64
pki-kra-10.8.2-2.module+el8.2.0+5796+110ac6eb.noarch
pki-symkey-10.8.2-2.module+el8.2.0+5796+110ac6eb.x86_64
pki-base-java-10.8.2-2.module+el8.2.0+5796+110ac6eb.noarch
pki-servlet-engine-9.0.7-16.module+el8.1.0+3366+6dfb954c.noarch
pki-ca-10.8.2-2.module+el8.2.0+5796+110ac6eb.noarch
pki-servlet-4.0-api-9.0.7-16.module+el8.1.0+3366+6dfb954c.noarch
pki-server-10.8.2-2.module+el8.2.0+5796+110ac6eb.noarch
python3-pki-10.8.2-2.module+el8.2.0+5796+110ac6eb.noarch

tomcatjss-7.4.1-2.module+el8.2.0+4573+c3c38c7b.noarch
jss-4.6.2-2.module+el8.2.0+4573+c3c38c7b.x86_64

Comment 13 shalini 2020-03-17 15:04:40 UTC
I re-verified on latest versions:

pki-tools-10.8.3-1.module+el8.2.0+5925+bad5981a.x86_64
pki-servlet-engine-9.0.7-16.module+el8.1.0+3366+6dfb954c.noarch
python3-pki-10.8.3-1.module+el8.2.0+5925+bad5981a.noarch
pki-servlet-4.0-api-9.0.7-16.module+el8.1.0+3366+6dfb954c.noarch
pki-server-10.8.3-1.module+el8.2.0+5925+bad5981a.noarch
pki-base-java-10.8.3-1.module+el8.2.0+5925+bad5981a.noarch
pki-ca-10.8.3-1.module+el8.2.0+5925+bad5981a.noarch
pki-kra-10.8.3-1.module+el8.2.0+5925+bad5981a.noarch
pki-symkey-10.8.3-1.module+el8.2.0+5925+bad5981a.x86_64
pki-base-10.8.3-1.module+el8.2.0+5925+bad5981a.noarch

jss-4.6.2-3.module+el8.2.0+5925+bad5981a.x86_64
tomcatjss-7.4.1-2.module+el8.2.0+4573+c3c38c7b.no

It failed in HSM environment. And key recovery failed with following error in SYNC and ASYNC :
    PKCS #12 Creation Failed java.lang.RuntimeException: Exception in EncryptedPrivateKeyInfo.createPBE: Unable to check wrapper: Key does not reside on the current token: key owning token=Internal Key Storage Token

After putting kra.legacyPKCS12=false in KRA's CS.cfg and restarting CA and KRA services, it again failed with following exception :
SEVERE: KRAService serviceRequest PKCS #12 Creation Failed org.mozilla.jss.crypto.TokenException: Failed to export EncryptedPrivateKeyInfo: (0) Unknown error

Comment 15 shalini 2020-03-17 15:51:53 UTC
Created attachment 1670838 [details]
KRA debug logs for HSM ker recovery failure

Attached logs are for error in Key recovery in HSM machine.
Changing state of bugzilla to ASSIGNED

Comment 19 Alex Scheel 2020-03-20 17:52:32 UTC
Checked in upstream:


commit a3a91a8e85d7f05de3c85b0ae6ad1c80cf7c5b55 (HEAD -> master, upstream/master, origin/master, origin/HEAD)
Author: Alexander Scheel <ascheel>
Date:   Tue Mar 17 12:54:49 2020 -0400

    Remove token key checks
    
    Previously we enforced strict token key matching: the primary key used
    for the operation must strictly reside on the current PKCS#11 token,
    otherwise JSS would bail. However, NSS has the ability to move the key
    to whichever token best supports the given operation. This means that
    we'd prematurely bail when the operation would succeed if it were
    actually executed. By removing these checks, we still leave the ability
    to generate keys on a specific token, we just allow them to be used on
    whatever token supports the given operation (and the key is allowed to
    be moved to).
    
    Signed-off-by: Alexander Scheel <ascheel>

Comment 31 errata-xmlrpc 2020-04-28 15:46:17 UTC
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/RHSA-2020:1644