0

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?

JustBeingHelpful
  • 18,332
  • 38
  • 160
  • 245
  • If you want to use the new CSR, it is as simple as doing the same steps as you did in the first place. And what was the certificate format given to you by the CA? – always_a_rookie Jun 07 '17 at 19:58
  • Is there a way to check the format with openssl? – JustBeingHelpful Jun 07 '17 at 20:10
  • I'm not sure, but opening it in a text editor or the extension of the file should give you some idea. – always_a_rookie Jun 07 '17 at 20:11
  • On the signed certificate (X.cer), the text between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" has 33 rows and 64 columns. The last row is missing 9 characters on the end. The private key (X.key) is a bit smaller. – JustBeingHelpful Jun 07 '17 at 20:15
  • It is probably just the user certificate, not the whole chain. You need to get the Sub CA's and the CA's certificate from the CA. The CA's usually have them on their website. You can see the 'Issuer DN' of your certificate to see which CA signed yours. Once you have the whole certificate chain, you can use the KeyStore api to construct the Java KeyStore with your private key and the whole certificate chain. Keytool doesn't provide this functionality of clubbing the certificate chain. It has to be done manually, which can be done using the KeyStore api. – always_a_rookie Jun 07 '17 at 20:24
  • The files were in X509 format. So the conversion from X509 to PKCS12 format using the first command, and the conversion from PKCS12 to JKS format using the second command was correct. I never did check with Symantec if they supplied the CA chain with the renewal. Seems like it should be a standard practice since we needed to use it for the JKS renewal when using a new CSR. For an existing CSR, it looks like the -importcert command would work instead of all this monkeying around. – JustBeingHelpful Jun 09 '17 at 21:25

1 Answers1

1

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)

JustBeingHelpful
  • 18,332
  • 38
  • 160
  • 245
  • You imported the signed certificate, not just the public key, into the client *truststore*. I don't know why you even had to do that for a CA-signed certificate. – user207421 Jun 13 '17 at 07:33
  • Is Oracle's documentation incorrect? https://docs.oracle.com/javase/tutorial/security/toolsign/step5.html – JustBeingHelpful Jun 13 '17 at 13:57
  • It is incorrect in that it conflates public keys with certificates, and keystores with truststores, but it is also completely and utterly irrelevant as it is about code signing with self-signed certificates, whereas your question is about CA-signed SSL certificates. It is also not 'documentation' but a tutorial, and so not a normative reference. – user207421 Jun 13 '17 at 20:25
  • I found this resource, but haven't tested anything yet. http://crishantha.com/wp/?p=445 – JustBeingHelpful Jun 13 '17 at 21:20
  • I'll probably ask another question since we're not quite sure what the correct command is to export the public key from a public PKI certificate. I would think the Symantec certificate keystore would have the same format as n the self-signed certificate keystore, and the commands would be identical. Since the end result keystore is identical. See the last couple commands related to self-signed keystore creation in the most upvoted answer here: https://stackoverflow.com/questions/906402/importing-an-existing-x509-certificate-and-private-key-in-java-keystore-to-use-i – JustBeingHelpful Jun 14 '17 at 22:51
  • Let's replace the wording of "PKI certificate" with "Java Keystore certificate that was converted from a Symantec public SSL certificate" and see if you can re answer, please. I'd like to make it clear that you can take a self signed certificate or a Symantec certificate and convert either to a Java Keystore. Once it is converted to the JKS on the server, that is the point in which I'd like to obtain the public key for the client which is authenticating to the server. Oracle seems to have provided this command in my second comment, yes? – JustBeingHelpful Oct 17 '17 at 04:40