Inserted Digital Certificate Does Not Have a Private Key Following Insert to ACF2 Database
Article ID: 52890
Updated On:
Products
Issue/Introduction
When receiving a certificate from another source and it is supposed to be the personal cert, the INSERT of the certificate from a dataset is successful, but when a CHKCERT command is used, there is no private key information listed. What happened to the private key?
Environment
Component: ACF2MS
Resolution
If the certificate in the dataset was in PKCS12 format with a private key, it is required to enter a password on the INSERT command or there would have been an error message ACF00184 PASSWORD IS INCORRECT. Issue a CHKCERT against the dataset to see if the private key is there. If the certificate in the dataset is in PKCS12 format and a password is not entered on the CHKCERT you will get the error message ACF68033 The password is incorrect for the CERTIFICATE. If that message does not occur and the CHKCERT output indicates there is no private key, then the key was either not sent by the originators, or the key was lost during interim processing. The originator will need to be contacted for another copy of the certificate in PKCS12 format with both its public and private keys.
For the certificate to be sent with the private key, it would have to be in PKCS12 format and would require a password to EXPORT it and, subsequently, to CHKCERT it or INSERT from it.
If the received certificate is meant to replace one currently in the ACF2 database with the same record id, perhaps with updated validity dates, then it is likely it does not have a private key. In this case it is assumed the private key from the original certificate remained on the database. If the original certificate was deleted, then its private key was deleted as well. If the original certificate has not been saved with its private key (in PKCS12 format) in another dataset, the only recourse is to start over and create a new certificate---and get it signed.
Feedback
