You MUST export the certificate in one of the PKCS12 formats to have the public and the private key. If you use any other formats like CERTDER or BASE64, it will only have the public key.
Client exported the certificate in PKCS12 format using a 3rd party application. They FTPed it to a dataset. When adding it, they received an invalid certificate format message from CA Top Secret.
Explained that depending on the certificate format, they need to FTP in binary or ASCII.
Knowledge document: http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/tec484087.aspx
He tried FTP in binary and then in ASCII, both failed with the same invalid certificate format message when adding the certificate to the security file via TSS ADD(CERTSITE) DIGICERT(MATRAP) DCDSN(datasetname) PKCSPASS(password).
Asked client to try exporting the certificate in PKCS12 format using OPENSSL and not that 3rd party windows application. Using OPENSSL worked. I am not that familiar with the 3rd party windows application he is using. It is probably not exporting the certificate in the right format for CA Top Secret.
Client decided to make CERTSITE the owner so multiple users can share this certificate on their keyring. If they make a particular user the owner of the certificate, only that user can use that certificate.
After adding the personal/client to the security file, we added it to a users keyring. They attempted the SSL connection iwith TOMCAT and it failed. They received a message stating certificate validation failed.
We listed the keyring and it only had the personal/client certificate. The root/signer certificate was missing from the keyring.
We added the signer/root certificate to the keyring.
KEYRING LABEL = MATRAP
KEYRING HAS THE FOLLOWING CERTIFICATES CONNECTED:
ACID(CERTSITE) DIGICERT(CAMATSM ) DEFAULT(NO ) USAGE(PERSONAL)
ACID(CERTAUTH) DIGICERT(AUTO0003) DEFAULT(NO ) USAGE(CERTAUTH)
TSS0300I LIST FUNCTION SUCCESSFUL
Recycling TOMCAT to pick up the changes and it started to work.