Section 1
Introduction

Section 2
Configuring for First Use

Section 3
Changing Admin Password

Section 4
Creating Accounts

Section 5
Global Component Settings

Section 6
Backups

Section 7
Log Files

Section 8
User Interface Settings

Section 9
Database Connections

Section 10
Non-Standard Ports

Section 11
Firewalls

Section 12
SSL

12.2 Which Components to Secure

12.3 Server Certificates

12.3 Server Certificates Continued

12.3 Server Certificates Continued

Section 13
Tracking and Recipient Profiles

Section 14
Editing INI Files

Section 15
Distributed Components

Section 16
User Interface Branding

Section 17
Evaluation Mode

Section 18
International Character Sets

Appendix A
Standard Default Ports

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:

-----BEGIN NEW CERTIFICATE REQUEST-----
tPnJhsLOuocsBYAmyM11qiZ5BEVWAnJfZ6kyN/XfT5NFxGIy9Uynz5kODfBwFUgiu98iQKWy
MKC/bGFuZ2VuMQ8wDQYDVQQKEwZMLVNvZnQxEDAOBgNVBAsTB1Vua25vd24xDzANB
gNVBAMTBnRlcHBp6E7Zyl9wkPyVpn1qbnbtXQGAablJInE9/LruaJ1NX1f/NVJgL4vPiDKsU4la
GvJHBNhdj+F0uVb3SIb3DQEBBAUAA4GBAB6XqdfJvhy7dTHijsHjw+c4ELQFI/TkHBvgp5NaC
ccQoNwwW9lnIeOikDb2lwWg56G6LiYfpVBss5+OOW2jXlq9CdNw1KLSDQ+kMtZjdVr8+iQ9g
sqxvskCAwEAAaAAMA0GCSqGMIIBpjCCAQ8CAQAwZjELMAkGA1UEBhMCREUxEDAOBg
NVBAgTB0dlcm1hbnkxETAPBgNVBAcTCEVyYzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwg
YkCgYEAz+hQRsqDWRLvmV4YD5+JaQEXn5qqJeyzkfg2PQoU2VPgHID0VnyTPt8r/t4uFk8p
1NxjYkC4
-----END NEW CERTIFICATE REQUEST-----

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:

Owner: OU=For VeriSign authorized testing only. No assurances (C)VS1997, OU=www.verisign.com/repository/TestCPS Incorp. By Ref. Liab. LTD., O="VeriSign, Inc"
Issuer: OU=For VeriSign authorized testing only. No assurances (C)VS1997, OU=www.verisign.com/repository/TestCPS Incorp. By Ref. Liab. LTD., O="VeriSign, Inc"
Serial number: 52a9f424da674c9daf4f537852abef6e
Valid from: Sun Jun 07 02:00:00 GMT+02:00 1998 until: Wed Jun 07 01:59:59 GMT+02:00 2006
Certificate fingerprints: MD5: 40:06:53:11:FD:B3:3E:88:0A:6F:7D:D1:4E:22:91:87 SHA1: 93:71:C9:EE:57:09:92:5D:0A:8E:FA:02:0B:E2:F5:E6:98:6C:60:DE
Trust this certificate? [no]:

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.

Tip icon 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.

 

Back One Page | Forward One Page