1

I have a product that initially used a keystore in which the certificate as the Owner and Issuer information as "unknown".

Now for security policy reasons and still guaranteeing back compatibility I have to update the Owner and Issuer information while retaining the original public/private key pair (for back compatibility).

Is it possible to do such thing?

Improve this question

1 Answer 1

Reset to default
2

TLDR: You can't modify a cert; you can and should replace it.

You can't change anything within a certificate because it is digitally signed precisely to prevent anyone from changing anything in it. However, you can get a new certificate for the same keypair but with new dates, different name(s), and possibly other changes.

No real CA issues a cert with either Owner (which is really Subject) or Issuer containing only 'unknown', much less both, so this is almost certainly the dummy (placeholder) self-signed cert created by keytool when it generates a keypair.

If you want to get a 'real' cert from an established, trusted Certificate Authority aka CA, you can do so with keytool; in fact this is the normal process:

  1. keytool -genkeypair: create keypair and selfsigned cert (in keystore)
  2. keytool -certreq: create Cert Signing Request aka CSR (for keypair in keystore)
  3. send CSR to CA along with evidence of identity (often, especially for SSL/TLS server, an Internet domain name, but sometimes another kind of identity) and if applicable payment
  4. receive/fetch new cert from CA along with any applicable 'chain' or 'intermediate' certs
  5. keytool -importcert: install new cert and chain into keystore

See the Java manual at e.g. https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html#keytool_examples . The details of steps 3 and 4 vary depending on the CA you use, and all CAs I've ever seen have customized instructions for issuing a cert to a Java system, often listed under Tomcat as the 'typical' Java system, tailored to that CA. You effectively have already done step 1 but with the wrong subject name, and need to complete the remaining steps with one variation:

  • in step 2 keytool -certreq add the option -dname 'newnamefields' (use " on Windows) to specify the corrected requester/Subject name for the CSR.

General info about cert names is on the same page at the heading X.500 Distinguished Names. If this cert (and key) will be for an SSL/TLS server, the Subject name should be or include 'CN=servername' where servername is not the name of a person as described in the manual, but instead the name, or a wildcard (in first component only) matching the name, of the server as it is accessed by client(s). For public/Internet servers this is usually a Fully Qualified Domain Name aka FQDN or in rare cases an IP address, but some intranet or LAN environments use other names.

Otherwise: if you want to create a new selfsigned cert, keytool does not have an option for that; you can write a program to do it, but it's easier, though a bit roundabout, to use OpenSSL instead. You can also use OpenSSL to request a real CA cert with some options that keytool doesn't support. If you are on Linux you most likely already have OpenSSL; on other Unix you may need to install it, almost always from the vendor's normal repository/channel/etc; on Windows (unless Windows10 with WSL) you will need to install the ShiningLight package. In outline this is:

  1. keytool -importkeystore -srckeystore jksfile -destkeystore tempp12 -deststoretype pkcs12 # convert from Java-only JKS to standardized PKCS12

  2. openssl pkcs12 -in tempp12 -nocerts -out tempkey # convert from PKCS12 to OpenSSL's 'private' PEM format

  3. For selfsigned: openssl req -new -x509 -inkey tempkey -validity days -out newcert and answer prompts for the name (or instead specify -subj 'namefields'); see man req on Unix for details, or on the web or earlier version as applicable. Then keytool -importcert -file newcert -keystore jksfile [-alias entry_if_not_mykey]

  4. For CA-signed: modify the OpenSSL config file (or a copy) if need then openssl req -new [-config conffile] -inkey tempkey [-subj 'namefields'] -out csrfile then submit this CSR to a CA in the same fashion as for Java above. When you get a new cert and its chain, do one of the following:

    4a. keytool -importcert the needed chain cert(s) to a different entry, or to different entries individually from the top down, then the EE cert to the same entry, as described for Java

    4b. combine the EE cert and its chain certs, all in PEM, into a single file, and keytool -importcert the whole chain to the same entry

    4c. use openssl pkcs12 -export to combine tempkey plus the (new) cert and chain into a single file say newp12, per man pkcs12 or here or earlier, then keytool -importkeystore -srckeystore newp12 -srcstoretype pkcs12 -destkeystore jksfile after deleting the old entry, or just deleting the file if this is only (desired) entry

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .