428 Error Using IBM MFA And Top Secret
Article ID: 245526
Updated On:
Products
Issue/Introduction
When attempting to use IBM MFA and Top Secret a RC 428 is received. Here is the definitions of a 428:
Record 'certname' does not have a private key
428 Key entry does not contain a private key.
Explanation The key entry does not contain a private key or the private key is not usable. This error can also occur if the private key is stored in ICSF and ICSF services are not available, if using a SAF key ring that is owned by another user, if the private key size is greater than the supported configuration limit or the application is executing in FIPS mode. Certificates that are meant to represent a server or client must be connected to a SAF key ring with a USAGE value of PERSONAL and either be owned by the user ID of the application or be SITE certificates. This error can occur when using z/OS PKCS #11 tokens if the user ID of the application does not have appropriate access to the CRYPTOZ class. This error can occur when using private keys associated with user certificates in a SAF key ring that is owned by another user if the user ID of the application does not have appropriate access to the ringOwner.ringName.LST resource in the RDATALIB class.
User response Ensure that the ICSF started task is started before the application if the private key is stored in ICSF. When using z/OS PKCS #11 tokens, ensure that the user ID has appropriate access to the CRYPTOZ class.
If executing in FIPS mode, ensure that the certificate that is being used does not have its private key stored in ICSF.
Environment
Release : 16.0
Component : Top Secret for z/OS
Resolution
The 'certname' certificate did not have a private key.
The original certificate was created in Top Secret via the TSS GENCERT command, then a certificate signing request (CSR) was generated for the certificate with TSS GENCERT, then the CSR sent to another group to be signed and sent back. When the original certificate was created, it was put on the MFAWEB started task ACID. When the CSR was returned by the other group, the certificate was added to CERTAUTH instead of the MFAWEB started task ACID. This caused the private key to be lost.
Here is the summary of the processing that is done using the GENCERT/GENREQ process:
1) When you do a TSS GENCERT(acid) …, the private key is stored on the ‘acid’ specified.
2) When you do the TSS GENREQ, the CSR is put to the dataset specified without the private key.
3) The dataset with the CSR is sent to the other group to be signed and is returned to you.
4) The new certificate (from the CSR) needs to be added to the SAME ACID used in the TSS GENCERT command in step 1. When it’s the same ACID, the private key is paired with the newly signed certificate.
If the same ACID in step 1 is NOT used in step 4, the private key is lost.
What happened is the certificate was GENCERTed using XX292 (MFAWEB stc ACID) in step 1 above, but in step 4, it was added to CERTAUTH ACID instead of XX292. This is why the private key was lost.
Unfortunately, you can’t just remove the certificate from the CERTAUTH ACID and then do another add of the new certificate to the MFAWEB started task ACID. You need go through the whole process again. Be sure to add the new certificate to the MFAWEB started task ACID.
To redo the 'certname' certificate to get the private key:
1) TSS GENCERT(mfawebacid) DIGICERT(certU) LABLCERT(MFATSTBU) …
2) TSS GENREQ(mfawebacid) DIGICERT(certU) DCDSN(dataset.name.unsigned)
3) Sent the CSR dataset from step 2 to the other group and received back the signed certificate.
4) Added the signed cert they received back to a new dataset.
5) TSS ADD(mfawebacid) DIGICERT(cert) LABLCERT(MFATSTB) DCDSN(new.dataset) TRUST
6) TSS ADD(mfawebacid) KEYRING(keyring) RINGDATA(mfawebacid,cert) USAGE(PERSONAL) DEFAULT
Notice in steps 1 and 2, the certificate name is certU (U for unsigned) and in steps 5 and 6, a different certificate name is used (cert)
Feedback
