** Plug in thr information in the lower case values.
** If the LABLCERT field is not used then the certificate label will default to the DIGICERT name. This is the best thing to do because it avoids the possibility of specifying the digicert name when the LABLNAME should be specified in application parmfile data. There may be applications that will require the certificate specific label. Follow the application documentation.
Create a CSR(Certificate Signing Request). This puts the certificate in a dataset in PKCS#10 format. PKCS#10 does not conatain the private key:
*** CAUTION NOTE*** Do not delete the original certU. It is holding the private key. If original certificate is deleted before pairing the keys (step 5) then the private key will be forever gone.
Send the certificate in the dataset to the Certificate Authority to be signed.
Receive the signed certificate from the CA(Certificate Authority) and put it into a dataset.
Add the certificate back to the owning acid with a slightly different name. It is good practice to give the certificates names ending in U for unsigned and S for signed:
** Note: A message that indicates that the certificate was added with NOTRUST may occur. This would be because the signing CA certificate is not in the Top Secret Database yet. The following TSS REPLACE command should be issued:
TSS REPLACE(acid) DIGICERT(certS) TRUST
The above ADD command paired the keys and there is now a signed certificate with a private key.
Create the KEYRING:
TSS ADD(acid) KEYRING(keyring)
** If the LABLRING field in not used then the keyring label will default to the keyring name. There may be applications that require the keyring label be a specific value. Follow the application documentation.
Note: If the owner of the client/personal certificate is not the owner of the keyring then specify ACCESS(CONTROL) on the PERMIT commands.
For the SERVER, a copy of the personal certificate needs to be sent to the client. The following command puts the certificate into a dataset without the private key: