12.2 Which Components Should Be Secured?

The Maestro User Interface and/or the Administration Hub component should only be secured with SSL - never the Maestro Tracker component. The Maestro Tracker component always requires use of normal HTTP; it cannot be configured to use HTTPS (because the collection of the tracking events needs to be fast, HTTPS is too slow for this).

As all components installed on one server share the same access method, it is necessary to select the access method for all components simultaneously. Therefore, if it is desired to secure the Administration Hub and/or Maestro User Interface components with SSL, they must be installed on a separate server (or separate servers) from the Maestro Tracker component (however, both may be on the same server, as long as they are both secured). Similarly, if only one component is to be secured (either the Administration Hub or the Maestro User Interface), then each component has to be secured on a separate server. This will permit security of one independent of the other.

12.3 Obtaining and Installing a Server Certificate

To enable LISTSERV Maestro to use HTTPS via SSL, obtain a signed server certificate for the server to be secured. It is not possible to simply obtain any server certificate and use it on any server. The certificate is always bound to the explicit server name that was chosen when the certificate was created. If the LISTSERV Maestro component is moved to a different server (with a different name), or the server is renamed, then a new certificate for the new name would have to be obtained.

Obtaining a server certificate involves three basic steps:

• Create an unsigned certificate with the name of the server being secured.

• Create a certificate signing request (CSR) from that certificate and send it to a certification authority (CA). The CA first verifies that the requester is genuine, and then returns a signed version of the certificate to the requester.

• Replace the unsigned certificate with the signed certificate returned by the CA.

Certificate administration happens with a command line tool called "keytool", that is installed together with Java. For more information about this tool, and further discussion about certificates and secure communication, see the relevant documentation at Sun's Web site: http://java.sun.com/j2se/1.3/docs/tooldocs/win32/keytool.html

12.3.1 Securing the Trusted Root Certificate Keystore

As a first step when starting to use certificates, be sure to secure the default keystore for trusted root certificates that is shipped with Java. The Java version that is installed together with LISTSERV Maestro follows a keystore that already contains trusted root certificates from some CAs (for example VeriSign and Thawte) This keystore is initially protected with the default password "changeit", which should be changed as soon as possible after the installation of LISTSERV Maestro.

To change the password of the default keystore, execute the following command:

HOME\j2sdk1.4.0_01\jre\bin\keytool -storepasswd -keystore DEFAULT_KEYFILE

with the following replacement:

HOME: The installation folder of LISTSERV Maestro, usually something similar to: "\Program Files\L-Soft\Application Server".

DEFAULT_KEYFILE: The filename of the default keystore file. Can either be a relative or a full path name. It is necessary to specify the name of the file "cacerts" in the following location: HOME\j2sdk1.4.0_01\jre\bin\keytool -storepasswd -keystore DEFAULT_KEYFILE (with HOME define as above).

Enter the old password first (this would be "changeit" if it has not been changed since installation of the JRE). Next, enter the new password twice. A new password must have at least six characters, however, longer and more complex passwords are safer!

12.3.2 Creating an Unsigned Server Certificate

In Java, all certificates are stored in a so-called "keystore," which is usually a special file protected with a password.

To add a certificate to a keystore, execute the following command:

HOME\j2sdk1.4.0_01\jre\bin\keytool -genkey -alias NAME -validity DAYS -keystore KEYFILE -keyalg RSA

with the following replacements:

HOME: The installation folder of LISTSERV Maestro, usually something similar to: "\Program Files\L-Soft\Application Server".

DAYS: Limits the validity of the certificate. The certificate will expire so many days after the day it was created. Can be any number of days. Usually, when the signing service from the CA is purchased, only a limited period during which the certificate shall be valid is paid for. Choose a number of days for this parameter, which is no shorter than the period purchased from the CA (a little padding here is probably a good idea, to be on the safe side). It is also possible to create a certificate that has a very long validity period (several years), if desired.

KEYFILE: The keystore file where the certificate will be added. It can either be a relative or a full path name. If the file does not exist, it is created. If it already exists, a certificate with the given "NAME" is added to it.

Note: This is not the same keystore file as the default keystore file that was used in Section 12.3.1, but a different keystore, where the server certificate is stored.

Choose a suitable location and file name for the keystore file that takes into account the special security considerations for this file as outlined below.

Be very careful with the keystore file where the certificate has been created. Protect this file in two respects:

• Do not "lose" or accidentally delete this file, as it contains the certificates. New certificates would have to be purchased in this event. Keep a backup at a safe location.

• Protect the file against unauthorized access. Even though the file is password protected, passwords can always be broken, and an attacker could thus gain access to the certificates.

The tool will first prompt for the entry of the password with which the keystore is protected. If an existing keystore is being used, enter its password. If a filename of a keystore that does not yet exist is given, then a new keystore will be created and it will be protected with the password that was entered at the first prompt (choose a password with at least six characters, remembering that longer and more complex passwords are safer).

Next, the tool will prompt for the following information values. Press RETURN each time to simply accept the default value "Unknown". However, some values must be entered for the certificate to work and some CAs require other values are filled out. So it is generally a good idea to fill out all values with whatever fits best in each case (see below).

What is your first and last name?

Here, the host name of the server to be secured with the certificate being created must be entered. Yes, even though the question reads "your first and last name," it is necessary to enter the host name of the computer instead! This should be the same host name that will be used in the URLs to access the server. For example, if the URL is "http://maestro.mycorp.com/lui", then enter the host name "maestro.mycorp.com" (without the quotes).

What is the name of your organizational unit?

What is the name of your organization?

What is the name of your City or Locality?

What is the name of your State or Province?

What is the two-letter country code for this unit?

Use the two-letter code that fits the country where the server is deployed, like US, DE, SE, CH, and so on.

After the last question is answered, a summary of the input and a request for confirmation will appear. Type "yes" and RETURN to accept the input, or "no" and RETURN (or simply RETURN) to reject it (in this case enter the values again until they are satisfactory). After the input is confirmed, the tool takes a few seconds to generate the certificate. When it is done, enter a password at the prompt to protect the certificate. Although generally any password is usable, for the certificate to be usable with LISTSERV Maestro, the same password chosen for the keystore itself must be used. To do so, simply press RETURN without entering anything, so that the default is accepted.

At this point, the certificate has been created, but it is as yet unsigned.