How A Private Key Of A Digital Certificate Is Managed

Document ID : KB000017733
Last Modified Date : 14/02/2018
Show Technical Document Details


When a certificate is genned, it's possible that it doesn't have a private key. This digital certificate is not usable.


The private key for a certificate is created by the entity that generates the certificate. If you use the TSS GENCERT/GENREQ commands in CA Top Secret, then the private key is created at GENCERT time. When you pass the certificate to the CA (Certificate Authority), there is no private key passed. By default, the CA will verify the certificate for you and pass it back also WITHOUT a private key. When you then add that certificate back into the CA Top Secret database, the new certificate will be reconnected to the original key.

This is all handled internally in CA Top Secret.

In the case of a certificate generated externally (ie by a third party vendor), the process is the same. The private key is generated when the certificate is first generated, for example, under Windows. You would then need to pass that certificate to a CA for verification. When the certificate is returned it must be brought back into Windows to be connected back up with the private key.
Once that process is complete, the certificate would then need to be EXPORTED from Windows and placed into a dataset.
This will require a password to be specified when the file is exported from Windows.

The certificate then needs to be ADDed into CA-Top Secret in order for it to be stored there. The add process would need to specify the same password as was used at EXPORT time. The export process will have copied the certificate WITH the private key. That is why the password is required. The TSS add command format could be:

LABELCERT(certificate label) 
TRUST PKCSPASS(user_specified_password) 

Thus, the certificate is not usable when there is no private key stored. You need to get the validated certificate with
the private key from Windows via an export. That you can add into CA-Top Secret.