6

Just wanted to ask this question as "Clarification" as opposed to a resolution:

java keytool has the -importcert command with -trustcacerts arg. From the offical help guideline.

Import the Certificate Reply from the CA

After you import a certificate that authenticates the public key of the CA you submitted your certificate signing request to (or there is already such a certificate in the cacerts file), you can import the certificate reply and replace your self-signed certificate with a certificate chain. This chain is the one returned by the CA in response to your request (when the CA reply is a chain), or one constructed (when the CA reply is a single certificate) using the certificate reply and trusted certificates that are already available in the keystore where you import the reply or in the cacerts keystore file.

For example, if you sent your certificate signing request to VeriSign, then you can import the reply with the following, which assumes the returned certificate is named VSMarkJ.cer:

keytool -importcert -trustcacerts -file VSMarkJ.cer

I also read the followin from keytool docs:

If the reply is a single X.509 certificate, keytool attempts to establish a trust chain, starting at the certificate reply and ending at a self-signed certificate (belonging to a root CA). The certificate reply and the hierarchy of certificates used to authenticate the certificate reply form the new certificate chain of alias. If a trust chain cannot be established, the certificate reply is not imported. In this case, keytool does not print out the certificate and prompt the user to verify it, because it is very hard (if not impossible) for a user to determine the authenticity of the certificate reply.

If the reply is a PKCS#7 formatted certificate chain, the chain is first ordered (with the user certificate first and the self-signed root CA certificate last), before keytool attempts to match the root CA certificate provided in the reply with any of the trusted certificates in the keystore or the "cacerts" keystore file (if the -trustcacerts option was specified). If no match can be found, the information of the root CA certificate is printed out, and the user is prompted to verify it, e.g., by comparing the displayed certificate fingerprints with the fingerprints obtained from some other (trusted) source of information, which might be the root CA itself. The user then has the option of aborting the import operation. If the -noprompt option is given, however, there will be no interaction with the user.

If I receive the certificate reply with both root CA and the my signed certificate, Which one is the correct command for me to import the certificates correctly (or will all of the below work based on root CA availability):

# Assuming doesn't exist at all
keytool -import -keystore server_keystore.jks -storepass pass -alias rootCA -file ca-cert-file
keytool -import -keystore server_keystore.jks -storepass pass -alias fqdn_name -file signed_server_cert

vs

#Assuming that root CA exists in system-wide cacerts
keytool -import -trustcacerts -keystore server_keystore.jks -storepass pass -alias fqdn_name -file signed_server_cert

vs.

# Assuming that the root CA doesn't exist
keytool -importcert -keystore java_home\jre\lib\security\cacerts -storepass changeit -alias someRootCA -file root_ca_cert
keytool -importcert -trustcacerts -keystore server_keystore.jks -storepass pass -alias fqdn_name -file signed_server_cert

Sorry for any incorrect assumptions, just trying to understand by collaborating with others :)

Regards,

ha9u63a7
  • 6,233
  • 16
  • 73
  • 108
  • What happened when you tried it? And if you only got one file in reply, how can #1 and #3 possibly be relevant? They both use two files. – user207421 Aug 06 '17 at 00:21
  • @EJP okay I missed out a change - Updated the question now. Thanks. My truststore cacerts got corrupted (i think) because I used `-trustcacerts` with both my server keystore and trust store. Just want to understand how not to mess up the order. I used `openssl s_client` command to check my server's behaviour when it was printing out quite a lot of certificate info, but no actual data write/read tests. – ha9u63a7 Aug 06 '17 at 00:25

1 Answers1

7
# Assuming doesn't exist at all
keytool -import -keystore server_keystore.jks -storepass pass -alias rootCA -file ca-cert-file
keytool -import -keystore server_keystore.jks -storepass pass -alias fqdn_name -file signed_server_cert

This is the one to use. You need the -trustcacerts option on the first one, or a 'yes' reply to the corresponding prompt.

#Assuming that root CA exists in system-wide cacerts
keytool -import -trustcacerts -keystore server_keystore.jks -storepass pass -alias fqdn_name -file signed_server_cert

This would work if the certificate that signed yours is in cacerts. This is usually not the case: the root certificate should be there, but probably they signed it with a certificate that is three or more steps deep from that.

# Assuming that the root CA is a new authority
keytool -importcert -keystore java_home\jre\lib\security\cacerts -storepass changeit -alias someRootCA -file root_ca_cert
keytool -importcert -trustcacerts -keystore server_keystore.jks -storepass pass -alias fqdn_name -file signed_server_cert

Looks OK in theory but if the CA is a new authority nobody else will trust it anyway, so this is futile.

Note that when you import the signed certificate you must use the same keystore file and alias you used when generating the keypair and CSR. This is a frequent source of error.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Thanks for the answer - I am trying to understand what you meant by "You need -trustcacerts on the first one, either as an option or as a reply to the prompt". Assuming no intermediate CA cert exists, isn't `-trustcacerts` meant to say "Establish chain of trust for this cert by looking into system-wide cacerts file" ? If you could kindly elaborate on this statement, it would be super cool. – ha9u63a7 Aug 06 '17 at 00:46
  • Yes it is. If you don't supply it, `keytool` will ask you whether you want to trust these certificates, and you must answer 'yes'. – user207421 Aug 06 '17 at 00:47
  • Awesome work. Thanks. And yes the alias name can mess things up – ha9u63a7 Aug 06 '17 at 00:49
  • Note also that it doesn't matter what the alias name actually is. It doesn't need to be an FQDN for example. – user207421 Aug 06 '17 at 00:54
  • actually if the SSL/TLS setup is, for example, between a list of servers working as distributed system - then it is better to get the certificate for a wildcard based SAN/CN - and you can match it with FQDN later. Of course, it's dependent on how server application is setup to do verificationi. – ha9u63a7 Aug 06 '17 at 10:12
  • @ha9u63ar Actualy that has nothing to do with the alias being an FQDN or not, which is what I was talking about. – user207421 Jan 29 '20 at 15:41