Section 1 Section 2 Section 3 Section 4 Section 5 Section 6 Section 7 Section 8 Section 9 Section 10 Section 11 Section 12 12.2 Which Components to Secure 12.3 Server Certificates Continued 12.3 Server Certificates Continued Section 13 Section 14 Section 15 Section 16 Section 17 Section 18 Appendix A |
12.3.3 Performing a Certificate Signing Request (CSR) Once an unsigned certificate has been created, generate a certificate signing request (CSR) from it, which can then be submitted to a certification authority (CA), for example VeriSign. To generate a CSR for a certificate in the keystore, execute the following command: HOME\j2sdk1.4.0_01\jre\bin\keytool -certreq -alias NAME -file OUTFILE -keystore KEYFILE with the following replacements: HOME: The installation folder of LISTSERV Maestro, usually something similar to: "\Program Files\L-Soft\Application Server". NAME: The name of the certificate. This must be the name of the certificate that the CSR is created for (the same name that was specified when the certificate was created). OUTFILE: The file where the CSR will be written. If the file already exists, it will be replaced with the new file. Can either be a relative or a full path name. KEYFILE: The keystore file where the certificate is stored. Can either be a relative or a full path name. The command will request the password of the keystore. After it is entered, the file specified as "OUTFILE" will be written. This file is a text file that contains the CSR in Base64-encoded form. An example of this file is shown below:
At this point, submit the CSR to the desired CA. For example, VeriSign offers an online order form that contains a field into which the text from the CSR can be simply pasted. Other CAs may do this differently - please ask the CA for help if there is any question, or if anything is unclear. After the CA has received the CSR, the CA will first verify that the requester or his/her company is indeed genuine, determining whether the content of the certificate can or cannot be trusted. This usually happens using methods such as making phone calls, checking company registrations, or other types of research, and may take a few days. Once the CA has verified the validity of the certificate, it will either be returned as a signed certificate, or instructions on how to obtain the signed certificate will be supplied. 12.3.4 Installing the Signed Server Certificate The signed certificate received back from the CA must be in X.509 format, either in binary or Base64 encoded form (please contact the CA if the certificate received does not match either of these formats). Once the certificate has been received, store it in a file (usually "*.cer"). Then execute the following command: HOME\j2sdk1.4.0_0\jre\bin\keytool -import -alias NAME -file INFILE -keystore KEYFILE -trustcacerts with the following replacements: HOME: The installation folder of LISTSERV Maestro, usually something similar to: "\Program Files\L-Soft\Application Server". NAME: The name of the certificate. This must be the name of the certificate that the CSR was made for (the same name that was specified when the certificate and the CSR were created). INFILE: The file that contains the reply from the CA with the signed certificate. KEYFILE: The keystore file in which the certificate is stored. Can either be a relative or a full path name. The command will load the certificate from the given file, check the signature of the signer (the CA) against a trusted root certificate of the CA and, if the signature matches, replace the unsigned version of the certificate that was in the keystore with the signed version. There is one critical moment here - when the tool tries to check the signature against a trusted root certificate of the CA: If this check cannot be made because such a trusted root certificate of the CA cannot be found, the tool will abort with an error message. In this case, obtain a trusted root certificate from the CA first, and then repeat the import step described above. Java is already shipped with trusted root certificates of certain CAs, like VeriSign and Thawte. For other CAs, obtain and install a root certificate first. See 12.3.5 Installing a Trusted Root Certificate for more information. 12.3.5 Installing a Trusted Root Certificate This step is only required if the signed server certificate was obtained from a CA for which a trusted root certificate is not already shipped with Java. An error message during the import of the signed certificate will occur if this is the case. The required root certificate should be available from the CA. The certificate must be stored in a file, either in "DER encoded binary X.509" or "Base-64 encoded X.509" format. If there is access to such a certificate file, import it into the keystore with the trusted root certificates by executing the following command: HOME\j2sdk1.4.0_0\jre\bin\keytool -import -alias NAME -file INFILE -keystore DEFAULT_KEYFILE with the following replacements: HOME: The installation folder of LISTSERV Maestro, usually something similar to: "\Program Files\L-Soft\Application Server". NAME: The name to be given to the certificate in the keystore. This name is not really important for anything, except for recognition at a later time. Also this name must not yet be in use in the keystore. INFILE: The file in which the X.509 certificate from the CA is stored. DEFAULT_KEYFILE: The file name of the default keystore file. Can either be a relative or a full path name. The name of the file "cacerts" needs to be specified in the following location: HOME\j2sdk1.4.0_01\jre\lib\security\cacerts The password of the default keystore file will be queried for, which should have been set to something other than its default "changeit" earlier. See 12.3.1 Securing the Trusted Root Certificate Keystore for more information. The command will present the details of the certificate to be imported in a way similar to the example below:
The presentation contains details about the certificate, but these could have been forged. It also contains the certificate's fingerprints, which can be used to verify that the certificate has not been falsified. For example, if the certificate was e-mailed (thus giving a potential attacker the possibility to "catch" the e-mail before it reaches its destination, and replacing the certificate therein with his own certificate for a future "man-in-the-middle" attack), then it is advisable to call the responsible person from the CA, to verify the fingerprint of the certificate over the phone. Once the certificate is believed to be genuine, answer "yes" and return to the question "Trust this certificate?" After this is done, the certificate is installed as a new trusted root certificate in the default Java root certificate store, and can now be used to import server certificates signed by the CA from which the root certificate was secured, as described in the 12.3.4 Installing the Signed Server Certificate. Internet Explorer comes (as many browsers do) with an extensive list of trusted root certificates. It also allows for those certificates to be exported to a file in the X.509 format required for import by "keytool". Therefore, if a CA is chosen to sign the server certificate for which there is no trusted root certificate already in the Java default keystore, it is very easy to locate a root certificate by exporting it from Internet Explorer as described below. This description is for IE 5.0, 5.5 and 6.0; other versions may vary. Go to "Tools -> Internet Options… -> Content tab -> Certificates… -> Trusted Root Certification Authorities tab" and look for a matching root certificate (Many CAs have several of these.) This might have to be done by trial-and-error until a matching certificate is found. Select the certificate and click on "Export…" In the export wizard, choose either "DER encoded binary X.509 (.CER)" or "Base-64 encoded X.509 (.CER)" and supply a suitable filename. Next, complete the export. The file that is exported can then be imported into Java's default keystore as described above.
|
||