Commands to renew a Java Keystore with a Symantec

Two years ago, I got a VeriSign/Symantec SSL certificate. When initiating this request, we created a CSR on a random server that is not associated with the common name of the certificate. To create a Java Keystore, I did the following two steps.

openssl pkcs12 -export -in common_name.cer -inkey common_name.key -out renewal.p12 -name common_name_alias -CAfile NewVerisignIM.cer -caname root

keytool -importkeystore -deststorepass XXX! -destkeypass XXX!
-destkeystore renewal.keystore -srckeystore renewal.p12 -srcstoretype PKCS12 -srcstorepass XXX! -alias common_name_alias

Now our certificate is about to expire. When using the original entry on the Symantec website, and creating a new CSR, we got the signed certificate file (same file name as common_name.cer above), the private key (same file name as common_name.key above). After signing the new CSR, we DID NOT get back the "NewVerisignIM.cer" file, which appears to be the root CA and intermediate CA combined in one file (aka the CA chain I believe). So I don't know how to recreate the Java Keystore without that file.

I tried using the old "NewVerisignIM.cer" with the new files after signing, but that did not work. That's all I've tried so far. I got a Java exception of

PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

This site contains instructions when using the original CSR and using a JKS.

https://knowledge.symantec.com/kb/index?page=content&id=SO11942&pmv=print&actp=PRINT&viewlocale=en_US

But this question/answer recommends using a new CSR.

Renew certificate with Java Keytool - reuse old CSR?

What commands can I use if we use the new CSR?

I had the commands correct. The new private key is needed in the first command (X509 to PKCS12). The new signed certificate is needed in the first command. And the original CA chain file, when the original certificate was created, is needed in the first command. The renewal did not contain this file as output. In 2015, Verisign probably had not been acquired by Symantec yet, so the file was named "NewVerisignIM.cer". The second command above converts from PKCS12 to JKS (Java Keystore) format.

My problem was that servers acting as the client who were authenticating against this server did not have the public key updated, because there was a new private key assigned in the renewal. Please note that this new private key is recommended by Symantec, but not required. So I had to export the certificate from the newly created JKS store after the conversion of those two commands on the server containing the common name of the renewal certificate, and then delete the old public key (entry) from the client Java Keystore (on a different server), and import the new public key, so it could talk to the server (with the renewal, and new private key).

Commands run on server (new keystore gets created):

openssl pkcs12 -export -in common_name.cer -inkey common_name.key -out renewal.p12 -name common_name_alias -CAfile NewVerisignIM.cer -caname root

keytool -importkeystore -deststorepass XXX! -destkeypass XXX!
-destkeystore renewal.keystore -srckeystore renewal.p12 -srcstoretype PKCS12 -srcstorepass ppp1 -alias common_name_alias

keytool -export -alias https-renewal -file https-renewal.pem -keystore renewal.keystore

Commands run on client (keystore remains the same):

keytool –delete –alias https-renewal –keystore original.keystore –storepass ppp2

keytool -import -v -alias https-renewal -file https-renewal.pem -keystore original.keystore -storepass ppp2

(where "https-renewal.pem" is the file exported from the 3rd command in this answer)