Bug 1386303 - cannot extract generated private key from KRA when HSM is used.
Summary: cannot extract generated private key from KRA when HSM is used.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 7.4
Assignee: Ade Lee
QA Contact: Asha Akkiangady
Marc Muehlfeld
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-18 15:30 UTC by Matthew Harmsen
Modified: 2020-10-04 21:18 UTC (History)
9 users (show)

Fixed In Version: pki-core-10.4.1-4.el7
Doc Type: Bug Fix
Doc Text:
Extracting private keys generated on an HSM no longer fails Previously, when generating asymmetric keys on a Lunasa or Thales hardware security module (HSM) using the new Asymmetric Key Generation REST service on the key recovery agent (KRA), PKI Server set incorrect flags. As a consequence, users were unable to retrieve the generated private keys. The code has been updated to set the correct flags for keys generated on these HSMs. As a result, users can now retrieve private keys in the mentioned scenario.
Clone Of:
Environment:
Last Closed: 2017-08-01 22:48:25 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github dogtagpki pki issues 2642 0 None closed cannot extract generated private key from KRA when HSM is used. 2020-10-09 14:51:52 UTC
Red Hat Product Errata RHBA-2017:2110 0 normal SHIPPED_LIVE pki-core bug fix and enhancement update 2017-08-01 19:36:59 UTC

Description Matthew Harmsen 2016-10-18 15:30:16 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/pki/ticket/2522

KRA has the ability to generate an asymmetric key set (public and private key).
When the key set is generated with a KRA that is backed by an NSS DB, there is no issue
retrieving either the public or private key.

When the key set is generated by a KRA backed with a nethsm, we can only extract the public key.

This needs to be fixed for Barbican.

Comment 1 Matthew Harmsen 2016-10-18 22:14:43 UTC
Per PKI Bug Council of 10/18/2016:   7.4

Comment 3 Ade Lee 2017-05-06 14:11:29 UTC
commit bea446868e282955d9c70028be657530eaccbe29
Author: Ade Lee <alee>
Date:   Mon May 1 18:25:59 2017 -0400

    Use AES-CBC in storage unit for archival in key wrapping
    
    When AES-KW or AES-KWP is not available, we need to be sure to use
    a key wrap algorithm that is available for keywrap.  This would
    be AES-CBC.  Removes some TODOs.
    
    Refactor so that getWrappingParams is only defined on the StorageUnit,
    which is where it makes sense in any case.
    
    Part of Bugzilla BZ# 1386303
    
    Change-Id: I28711f7fe0a00e9d12d26c6e170fb125418d6d51

commit f84bfab30647ae1492fcdca0a026bfa4d91350c9
Author: Ade Lee <alee>
Date:   Mon May 1 15:56:58 2017 -0400

    Make sure generated asym keys are extractable
    
    In HSMs, we were not able to retrieve asym keys that were
    generated from the AsymKeyGenService, because the right
    flags were not set (ie. set like in the server side
    keygen case).
    
    To do this, I extracted the key generation function from
    NetKeygenService to KeyRecoveryAuthority, so that it could
    be used by both services.
    
    Bugzilla BZ# 1386303
    
    Change-Id: I13b5f4b602217a685acada94091e91df75e25eff

Comment 5 Sumedh Sidhaye 2017-05-16 09:05:50 UTC
Build used for verification :

[root@csqa4-guest01 hsm_setup]# rpm -qi pki-base
Name        : pki-base
Version     : 10.4.1
Release     : 4.el7
Architecture: noarch
Install Date: Monday 15 May 2017 12:35:11 AM EDT
Group       : System Environment/Base
Size        : 2086209
License     : GPLv2
Signature   : RSA/SHA256, Tuesday 09 May 2017 11:33:58 PM EDT, Key ID 199e2f91fd431d51
Source RPM  : pki-core-10.4.1-4.el7.src.rpm
Build Date  : Tuesday 09 May 2017 09:23:16 PM EDT
Build Host  : ppc-021.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://pki.fedoraproject.org/
Summary     : Certificate System - PKI Framework


RHCS setup used:
CA and KRA instances have been setup on a system connected to HSM

[root@csqa4-guest01 hsm_setup]# certutil -L -d /var/lib/pki/rhcs92-KRA-ssidhaye-May15-2/alias -h NHSM-SSIDHAYE-SOFTCARD -f /tmp/password.txt 

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

NHSM-SSIDHAYE-SOFTCARD:transportCert cert-rhcs92-KRA-ssidhaye-May15-2 KRA u,u,u
NHSM-SSIDHAYE-SOFTCARD:storageCert cert-rhcs92-KRA-ssidhaye-May15-2 KRA u,u,u
NHSM-SSIDHAYE-SOFTCARD:Server-Cert cert-rhcs92-KRA-ssidhaye-May15-2 u,u,u
NHSM-SSIDHAYE-SOFTCARD:subsystemCert cert-rhcs92-KRA-ssidhaye-May15-2 u,u,u
NHSM-SSIDHAYE-SOFTCARD:auditSigningCert cert-rhcs92-KRA-ssidhaye-May15-2 KRA u,u,Pu
NHSM-SSIDHAYE-SOFTCARD:caSigningCert cert-rhcs92-CA-ssidhaye-May15-2 CA CTu,Cu,Cu
NHSM-SSIDHAYE-SOFTCARD:ocspSigningCert cert-rhcs92-CA-ssidhaye-May15-2 CA u,u,u
NHSM-SSIDHAYE-SOFTCARD:Server-Cert cert-rhcs92-CA-ssidhaye-May15-2 u,u,u
NHSM-SSIDHAYE-SOFTCARD:subsystemCert cert-rhcs92-CA-ssidhaye-May15-2 u,u,u
NHSM-SSIDHAYE-SOFTCARD:auditSigningCert cert-rhcs92-CA-ssidhaye-May15-2 CA u,u,u


Certificate request with key archival
[root@csqa4-guest01 hsm_setup]# pki -d nssdb -c SECret.123 -h localhost -p 8080  client-cert-request "uid=foo1" --profile caDualCert --type crmf --transport transportCert.pem 
-----------------------------
Submitted certificate request
-----------------------------
  Request ID: 14
  Type: enrollment
  Request Status: pending
  Operation Result: success
[root@csqa4-guest01 hsm_setup]# pki -d nssdb -c SECret.123 -h localhost -p 8080 -n "PKI CA Administrator for Non-TMS-CA" cert-request-review 14 --action approve
WARNING: BAD_CERT_DOMAIN encountered on 'CN=csqa4-guest01.idm.lab.eng.rdu.redhat.com,OU=rhcs92-CA-ssidhaye-May15-2,O=Example-rhcs92-CA' indicates a common-name mismatch
-------------------------------
Approved certificate request 14
-------------------------------
  Request ID: 14
  Type: enrollment
  Request Status: complete
  Operation Result: success
  Certificate ID: 0xe

[root@csqa4-guest01 hsm_setup]# pki -d nssdb -c SECret.123 -h localhost -p 20080 -P https -n "PKI Administrator for idm.lab.eng.rdu.redhat.com" key-find
WARNING: BAD_CERT_DOMAIN encountered on 'CN=csqa4-guest01.idm.lab.eng.rdu.redhat.com,OU=rhcs92-KRA-ssidhaye-May15-2,O=idm.lab.eng.rdu.redhat.com Security Domain' indicates a common-name mismatch
----------------
2 key(s) matched
----------------
  Key ID: 0x1
  Client Key ID: test_symkey1
  Status: active
  Algorithm: AES
  Size: 256
  Owner: kraadmin

  Key ID: 0x2
  Algorithm: 1.2.840.113549.1.1.1
  Size: 1024
  Owner: UID=foo1
----------------------------
Number of entries returned 2
----------------------------

Retrieve the private that was archived when crmf request was submitted
[root@csqa4-guest01 hsm_setup]# pki -d nssdb -c SECret.123 -h localhost -p 20080 -P https -n "PKI Administrator for idm.lab.eng.rdu.redhat.com" -n "KRA_AgentV" key-retrieve --keyID 0x2
WARNING: BAD_CERT_DOMAIN encountered on 'CN=csqa4-guest01.idm.lab.eng.rdu.redhat.com,OU=rhcs92-KRA-ssidhaye-May15-2,O=idm.lab.eng.rdu.redhat.com Security Domain' indicates a common-name mismatch
------------------------
Retrieve Key Information
------------------------
  Key Algorithm: 1.2.840.113549.1.1.1
  Key Size: 1024
  Nonce data: q8qAAbC0WvlvaXusiUoHfg==

  Actual archived data: MIICdwIBADANBgkqhkiG9w0BAQEFAASCAmEwggJdAgEAAoGBAKt1d6yPBK5eUaV/
Apezz5CR/POTZ/yJ1wZHMPNpi1G2ZMuNjZ6rPWthjOw+aAJRGjXT1TYEEcTJqd9t
3g+1CsZSoMGg/c7NTN45bbZZooxz2Nmq1JSmqByKf7NBlpzmjk7SKFQ5XeJ62XAC
ZkNVbocq0ZhWl2CTUXkaR77jK6DtAgMBAAECgYAq6JXPgGcqf/4szZFHh79NLcvA
5UXjxFckghJ1CBfOlje5XS5w4+fWBK6wvJlo4wUNLXsxLmmH9vPlL2igQ61zNXID
ujptrNr3Wpzp+GczotQIHXFXHZ5S9jgnGs1EvYDRPJoaGEGtWAl0KbzzOjCmLA53
9YO2ZidFShs4EoPhHQJBANk+JG2NI9J482w5Y90NFKf92k+HRHIO00SLJxlUVaiO
rOJSXj9wGKLfA4yB9AbCpOa0EjtQM8SRVOFXP85H8h8CQQDKDEtwL+iRVV+T3nr0
kOjZtKXFM1zdZrBkZAFBVh/NY1B/yl5EytC7StpL8v+LTEY2voNIGJWHeGWCFwgh
jINzAkBckBHNa9nbkBWIA1v9j9lBSvR99lC/mHmENxZNwJVO4JvhQt9NgGG+4+8L
K0PirYS9l/Q8uYuVMadM7HQPXLBZAkEAkAYLkEDWSyLMKp+gjczt7qHyuItQWxHk
EuumaWh26vUsYKtkXy0jdR56VUE2H5mTQ1qyQiYkEJkl4oGAbkm3OQJBAM5c5R4+
Gp+1MQv+Ktg6DFlezotywpI/5Ak6anE4bmQmNLZzfLlLm2XNMVlmdJNKPvMQCKer
uFSeuTZSowgIteU=

[root@csqa4-guest01 hsm_setup]#

Comment 7 Ade Lee 2017-07-26 15:59:52 UTC
Looks good.

Comment 8 errata-xmlrpc 2017-08-01 22:48:25 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/RHBA-2017:2110


Note You need to log in before you can comment on or make changes to this bug.