Top Secret

Ok, I'm back to certificates.  As an almost-completely clueless noob I created two certificates for our upgraded Telnet server, and they've gotten it to work.  Now I have to copy those certificates to other LPARs so the same Telnet emulators can connect to those LPARs also.  I thought it would be simple: export the two certificates (one CERTSITE and one CERTAUTH), import them into the other LPARs, hook them up to keyrings there.  Done.

Apparently it's not that simple, and I'm a little tired of charging my client for the time I need to guddle around in the documentation looking for explanations.  Can anyone advise me?

I've exported the two certificates to a dataset in a PKCS12 packet, and CHKCERT seems to see it correctly.  Apparently the DIGICERT name is not copied during the EXPORT, nor USAGE, nor the TRUST setting; those I suppose I must supply when doing the ADD command.  I'll try it, at least.  But when I attempt an ADD command, it names the CERTAUTH cert "AUTOnnnn"; I didn't expect that.  Don't I need to rename it before it can be used, or does the client app not care?  Maybe it cares only about the distinguished names?  I'm sort of floundering here.  Eager to learn, though.

Bob,

AUTOnnnnn is used for the root certificate, if there client and root in the same dataset being added to CA Top Secret.

Browse the dataset and see if there are two certificates;

Try a TSS CHKCERT DCDSN(datasetname) PKCSPASS(password)  and see what it says.

If there isnt 2 certificates in  the dataset, then open a ticket with support for further investigation.

Regards,

Joseph Porto - CA Level 1 Support

Thanks for trying, Joe, but read my question again, please.  As I said, CHKCERT shows that the two certificates are in the dataset.  My question is still this:  When I "import" them from the dataset, it names the CERTAUTH certificate "AUTO0003".  Does this matter?  Must I (can I) import them separately, or is there a way to rename the signing cert after the import, or what?  The command I used to do the import is

   tss add(certsite) dcdsn(pkcs12_dsn) digicert(ARCRF222) pkcspass(password)

...where ARCRF222  is the CERTSITE cert.  The CERTAUTH cert was originally named ARCCA022, and I supposed it would keep that name.  The problem is that I've never done these before and I'm repeatedly finding that reality resolutely declines to fit itself to my assumptions.

Hi Bob,

It really doesn't matter what the name of the CERTAUTH certificate is but it would be easier to have the same certificate named the same on each LPAR.  So I would suggest that you EXPORT the CA Certificate AUTO0003 into a dataset.  I am not sure if this is a third party CA so I don't know if there is a private key or not but if there isn't then it is a simple EXPORT command and if there is then you would need to use FORMAT(PKCS12DER) and PKCSPASS(password) to ensure that the private key is exported.  Do a CHKCERT on the dataset and make sure it looks correct.  If all is good then you can remove the AUTO0003 certificate from CERTAUTH.  Now you can ADD the certificate back to CERTAUTH from the dataset (using the password if it was exported with one) and use the DIGICERT name that you like,  ARCCA022.   Just be careful that you have read the CHKCERT and that all the fields are correct in the dataset before you REMOVE the current certificate version from CERTAUTH.

Cheers,

  ~Eileen~

Right you are, Eileen; once we got past another problem, the certificates worked without my having to change the name.  You and I are agreed, though, that it'd be better to have them named the same across all the LPARS, so I'll go over your instructions carefully.

One question, though, a matter of clarification only:  You wrote "I am not sure if this is a third party CA so I don't know if there is a private key...".  Unless I'm missing something fundamental, every digital certificate has a private and a public key, whether it's issued by a CA or is self-signed.  Right?  Please say yes or I'll be terribly confused.

Hi Bob,

Yes, every certificate has a private and public key when it is created (genned).  However, you can separate the private key from the public key and this is common practice when you send your certificate to a Third Party CA such as Verisign, GoDaddy, Entrust ect...  I do not want to confuse you so I will just stick with the CA Certificates and the context of my statement.  If you send a certificate to be signed by a Third Party CA, they send you back the signed certificate and a version of the CA Certificate that they used to sign the certificate with.  You are only paying, (most of the time, unless you purchase a CA Certificate from them), to have your certificate signed. So the version of the CA Certificate that they send you will not have a private key.  They own the certificate so they hang onto the private key.  Now, if you were to create(gen) your own CA certificate and then use that to sign a personal(site) certificate that you create(gen) then you will not only have the private key of the personal certificate but also the private key of the CA Certificate.....because you own/created both of them.  Hope that makes sense ;-)

Cheers,

  ~Eileen~