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:
In an HSM setup, we have subsystem certificate resides on HSM.We can use subsystem certificate for issuance protection certification.
By default, the subsystem certificate (specified under cert.subsystem.nickname in the CA's CS.cfg), is used as the issuance protection certification. However, it is strongly advised that the administrator generate a different system certificate and dedicate that to this role. To configure such dedicated issuance protection certificate, the configuration parameter, cert.issuance_protection.nickname, must be specified
So if we try to use a certificate which we generate later for using as issuance protection certificate but it is not in HSM but it is in nssdb(internal token) in that case we are seeing failures.
Version-Release number of selected component (if applicable):
10.5
How reproducible:
always
Steps to Reproduce:
I created a cert using CA and now i used this "cert" .
1. CMCSharedToken -v -d . -p SECret.123 -s wonderfulday -o test -n "cert"
[root@csqa4-guest04 75]# CMCSharedToken -v -d . -p SECret.123 -s wonderfulday -o test -n "cert"
passphrase String = wonderfulday
passphrase UTF-8 bytes =
[119, 111, 110, 100, 101, 114, 102, 117, 108, 100, 97, 121]
Getting cert by nickname: cert
Generating session key
Encrypting passphrase
Wrapping session key with issuance protection cert
Encrypted Secret Data:
MIGVBIGAcS0iOcsoHThSL0Bk4bGkfznPng5DlSUem4R8iGB9XQlSCE130ZqN9NgH
lkyE3mM41mPuZNSZk9S4eyUAWBGdo9maF/oJnLa69TqdVE6sTAMyaMumiEZuFqP2
lK4Uw3zq45gZ6X7prdRi0woXj3VfafIO+4I787eW33VbloSQb04EEEmNl1a8mQde
ee1xmpBRxO8=
Storing Base64 secret data into test
2. So the certificate is :
certutil -L -d /etc/pki/rhcs-0day-trial-75/alias
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
caSigningCert cert-rhcs-0day-trial-75 CA CT,C,C
auditSigningCert cert-rhcs-0day-trial-75 CA ,,P
Server-Cert cert-rhcs-0day-trial-75 ,,
cert u,u,u
3. Stop instance. Put cmc.token=internal in CS.cfg and cert.issuance_protection.nickname=cert in CS.cfg. Start instance.
4. Run PKCS10Client, CMCRequest, HttpClient.
5. Output:
[20/Dec/2017:05:24:35][http-bio-28443-exec-2]: SharedSecret.getSharedToken(String identification): searching for identification =user2a; mShrTokAttr =shrTok
[20/Dec/2017:05:24:35][http-bio-28443-exec-2]: In LdapBoundConnFactory::getConn()
[20/Dec/2017:05:24:35][http-bio-28443-exec-2]: masterConn is connected: true
[20/Dec/2017:05:24:35][http-bio-28443-exec-2]: getConn: conn is connected true
[20/Dec/2017:05:24:35][http-bio-28443-exec-2]: getConn: mNumConns now 4
[20/Dec/2017:05:24:35][http-bio-28443-exec-2]: SharedSecret.getSharedToken(String identification): got entryShrTok
[20/Dec/2017:05:24:35][http-bio-28443-exec-2]: SharedSecret.decryptShrTokData: wrapped session key retrieved
[20/Dec/2017:05:24:35][http-bio-28443-exec-2]: SharedSecret.decryptShrTokData: wrapped passphrase retrieved
[20/Dec/2017:05:24:35][http-bio-28443-exec-2]: SharedSecret.decryptShrTokData: java.security.InvalidKeyException: Key does not reside on the current token
[20/Dec/2017:05:24:35][http-bio-28443-exec-2]: SharedSecret.getSharedToken(String identification): returning
[20/Dec/2017:05:24:35][http-bio-28443-exec-2]: returnConn: mNumConns now 5
[20/Dec/2017:05:24:35][http-bio-28443-exec-2]: EnrollProfile:verifyIdentityProofV2: Failed to retrieve shared secret
[20/Dec/2017:05:24:35][http-bio-28443-exec-2]: SignedAuditLogger: event CMC_PROOF_OF_IDENTIFICATION
Actual results:
Failed with "SharedSecret.decryptShrTokData: java.security.InvalidKeyException: Key does not reside on the current token"
Expected results:
This should work.
Additional info:
Discussed with devel team. Below is the response:
> Question :--Not sure why it failed with "Key does not reside on the current token" because key is with internal db??
(devel)The private key of the issuance protection cert needs to be on the same token as the current token. And by default since the system is setup using hsm, it will use it as current token.
I guess I could add code to force the current token to be that of the cmc.token.
I suggest you just file a separate bug and target it for after 7.5 as an enhancement.
Workaround:
----------
In the mean time, just always set cmc.token to the same hsm where you setup your system.
Description of problem: In an HSM setup, we have subsystem certificate resides on HSM.We can use subsystem certificate for issuance protection certification. By default, the subsystem certificate (specified under cert.subsystem.nickname in the CA's CS.cfg), is used as the issuance protection certification. However, it is strongly advised that the administrator generate a different system certificate and dedicate that to this role. To configure such dedicated issuance protection certificate, the configuration parameter, cert.issuance_protection.nickname, must be specified So if we try to use a certificate which we generate later for using as issuance protection certificate but it is not in HSM but it is in nssdb(internal token) in that case we are seeing failures. Version-Release number of selected component (if applicable): 10.5 How reproducible: always Steps to Reproduce: I created a cert using CA and now i used this "cert" . 1. CMCSharedToken -v -d . -p SECret.123 -s wonderfulday -o test -n "cert" [root@csqa4-guest04 75]# CMCSharedToken -v -d . -p SECret.123 -s wonderfulday -o test -n "cert" passphrase String = wonderfulday passphrase UTF-8 bytes = [119, 111, 110, 100, 101, 114, 102, 117, 108, 100, 97, 121] Getting cert by nickname: cert Generating session key Encrypting passphrase Wrapping session key with issuance protection cert Encrypted Secret Data: MIGVBIGAcS0iOcsoHThSL0Bk4bGkfznPng5DlSUem4R8iGB9XQlSCE130ZqN9NgH lkyE3mM41mPuZNSZk9S4eyUAWBGdo9maF/oJnLa69TqdVE6sTAMyaMumiEZuFqP2 lK4Uw3zq45gZ6X7prdRi0woXj3VfafIO+4I787eW33VbloSQb04EEEmNl1a8mQde ee1xmpBRxO8= Storing Base64 secret data into test 2. So the certificate is : certutil -L -d /etc/pki/rhcs-0day-trial-75/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI caSigningCert cert-rhcs-0day-trial-75 CA CT,C,C auditSigningCert cert-rhcs-0day-trial-75 CA ,,P Server-Cert cert-rhcs-0day-trial-75 ,, cert u,u,u 3. Stop instance. Put cmc.token=internal in CS.cfg and cert.issuance_protection.nickname=cert in CS.cfg. Start instance. 4. Run PKCS10Client, CMCRequest, HttpClient. 5. Output: [20/Dec/2017:05:24:35][http-bio-28443-exec-2]: SharedSecret.getSharedToken(String identification): searching for identification =user2a; mShrTokAttr =shrTok [20/Dec/2017:05:24:35][http-bio-28443-exec-2]: In LdapBoundConnFactory::getConn() [20/Dec/2017:05:24:35][http-bio-28443-exec-2]: masterConn is connected: true [20/Dec/2017:05:24:35][http-bio-28443-exec-2]: getConn: conn is connected true [20/Dec/2017:05:24:35][http-bio-28443-exec-2]: getConn: mNumConns now 4 [20/Dec/2017:05:24:35][http-bio-28443-exec-2]: SharedSecret.getSharedToken(String identification): got entryShrTok [20/Dec/2017:05:24:35][http-bio-28443-exec-2]: SharedSecret.decryptShrTokData: wrapped session key retrieved [20/Dec/2017:05:24:35][http-bio-28443-exec-2]: SharedSecret.decryptShrTokData: wrapped passphrase retrieved [20/Dec/2017:05:24:35][http-bio-28443-exec-2]: SharedSecret.decryptShrTokData: java.security.InvalidKeyException: Key does not reside on the current token [20/Dec/2017:05:24:35][http-bio-28443-exec-2]: SharedSecret.getSharedToken(String identification): returning [20/Dec/2017:05:24:35][http-bio-28443-exec-2]: returnConn: mNumConns now 5 [20/Dec/2017:05:24:35][http-bio-28443-exec-2]: EnrollProfile:verifyIdentityProofV2: Failed to retrieve shared secret [20/Dec/2017:05:24:35][http-bio-28443-exec-2]: SignedAuditLogger: event CMC_PROOF_OF_IDENTIFICATION Actual results: Failed with "SharedSecret.decryptShrTokData: java.security.InvalidKeyException: Key does not reside on the current token" Expected results: This should work. Additional info: Discussed with devel team. Below is the response: > Question :--Not sure why it failed with "Key does not reside on the current token" because key is with internal db?? (devel)The private key of the issuance protection cert needs to be on the same token as the current token. And by default since the system is setup using hsm, it will use it as current token. I guess I could add code to force the current token to be that of the cmc.token. I suggest you just file a separate bug and target it for after 7.5 as an enhancement. Workaround: ---------- In the mean time, just always set cmc.token to the same hsm where you setup your system.