As described in the section regarding the use of non-standard ports and installing behind a firewall, the LISTSERV® Maestro components can be configured in a way that users and/or administrators can access the Maestro User Interface and/or the Administration Hub with a Web browser from anywhere on the Internet.
This feature allows, for example, LISTSERV® Maestro to be set up in an ASP-environment, where the customers access the application over the Internet. Providing access to users from the Internet exposes the risk of unauthorized access. LISTSERV® Maestro uses password authentication as a first barrier against intruders. However, network traffic as such is a public affair. Anyone with the right knowledge and access to certain nodes in the network may eavesdrop on the communication between the user's browser and the LISTSERV® Maestro server. Intruders may gain knowledge about the data that is sent to the user's browser (for display) and sent back to the server (to trigger a certain action or to submit settings the user made). Even more dangerous, the intruder could find out the user name and password that the user or administrator uses for login, and could then log in him/herself with the same account.
If security is a concern, consider securing access to the LISTSERV® Maestro servers with encrypted communication, so that intruders cannot listen in on the communication between browser and server, and cannot gain knowledge about the data exchanged or spy out passwords. Standard browsers do all support encrypted communication via Secure Sockets Layer (SSL), using the HTTPS protocol to access web pages, instead of the normal HTTP protocol.
LISTSERV® Maestro also offers the possibility of using SSL for communication with the Administration Hub and/or the Maestro User Interface components. Since topics such as encryption, server certificates, and trusted authorities are so complex, an introduction is presented in 12.1 Introduction to Secure Communication of this guide to assist understanding the concepts involved, making the execution of the required steps easier.
This section is intended to provide a short introduction about the basics of secure communication. Please see the many publications about this topic for more details. Basically, for successful encrypted communication to take place one partner holding an "encryption key" encrypts the data. It is transferred to the second partner and decrypted using the same "key". One requirement is that both communication partners know the encryption key, so that the receiving partner may decrypt the data that was encrypted by the sending partner.
With online communication however, this is slightly complex. Both partners (the browser and the server), are most likely communicating with each other for the first time, and do not have a common encryption key that is known only to them. So, when the connection is first established, the two partners must secretly decide at the spur of the moment on an encryption key that will be used for the rest of the communication (this is a simplified view of the matter, but it explains the basics).
Assuming that both partners have decided what key to use, they can now communicate in an encrypted manner. There is still the problem of being sure that each partner is actually communicating with the partner they think they are communicating with. An analogy to this problem can be found in real life. Let's say that two employees of two partner companies meet in a hotel to exchange confidential information. The two have never met each other, but they know each other's names and home addresses. How can each of them be sure that the other person they meet in the lobby of the hotel is actually the person they are supposed to meet and not an impostor?
An impostor could act as a "man-in-the-middle". He meets with employee A of corporation A-Corp in the lobby and poses as employee B of corporation B-Corp. Thus, he gains confidential information from A and goes into the bar where he meets the real employee B. Here he poses as employee A from A-Corp, gives the confidential information from the "real" A to B and receives similar information back from B. Finally he goes back into the lobby relays the information he received from B to the "real" employee A. On his way from the lobby to the bar and back, he made copies of the information he was carrying. In the end, both employee A and B are unaware that they did not talk to their "real" counterparts, but to an impostor that acted as a "man-in-the-middle", and the impostor goes back to his employer C-Corp with the confidential information he gained from their competitors.
On a network this "man-in-the-middle" attack is even easier to mount. The only thing that a server and a client know from each other is their addresses, which can easily be forged. In real life, the two employees of A-Corp and B-Corp would probably request to see some picture ID with name and home address of their communication partner. They would then compare the picture on the ID with the person they are talking to and verify that the name and address on the ID matches the ones they have previously been told. If the ID matches the person, they would be confident that they are talking to the right person.
But, in doing so, they actually implicitly trust a third party that has not yet been involved. This would be the agency that issued the picture ID. With accepting the ID they trust that the agency has created an ID that it is hard to forge. They also trust that this agency has, in turn, verified that the person they issued the ID to really is the person he/she claims to be. If employee A had tried to use his/her library card for identification, then employee B would probably have rejected it as improper identification, because he/she would not trust either that the clerk in the library responsible for issuing the ID really did a thorough check of A's identity, or he did not trust the security features of the ID, (these days anyone can create an authentic looking ID with the help of a color laser printer). So instead he would probably request a "proper" ID like a passport or driver's license.
With online communication, the problem of identifying the communication partner is solved very similarly. The role of a "picture ID" in real life is fulfilled by so called "certificates" in the online world. A certificate asserts that the owner of the certificate is, in fact, the entity it claims to be. For example, a certificate could assert that the server with the host name "host.somecorp.com" actually is a server that belongs to SomeCorp, and that it is not an impostor's server.
How can such credibility problems be solved? Simply falsifying a file that states, "Yes, the server 'host.somecorp.com' is indeed a server belonging to the SomeCorp Corporation," would not be cumbersome for an intruder. To guard against this, the certificate is digitally signed by a trustworthy authority, so that it now reads, "Yes, the server 'host.somecorp.com' is a server belonging to the SomeCorp corporation, and we, the people from TrustCorp have verified that this is indeed so."
The digital signature is very useful because it prevents anyone from tampering with the certificate. If even a single letter (or byte) in the text of the certificate is changed, the signature will no longer match and the certificate will be invalid. However, a last problem remains: how to test the validity of the signature? The digital signature of the certificate was created using a signature key. The signature key consists of two parts, a private key and a public key. The signer (e.g. the signing authority) uses both parts to create the signature. The private key is held secret by the signer so that only the signer is able to use it to create a signature and a signature cannot be created with the public key alone.
The public key on the other hand is made public. It can be used by anyone who desires to test the validity of a digital signature that is supposed to come from the owner of the public key. With a certain algorithm, the signature is tested against the public key, producing a result that states (if the signature was valid): "Yes, the data signed by this signature has not been tampered with and it was signed with a private/public key pair, where the public key matches the public key that was used to test the signature." If the signature was not valid, the result could be "The data was tampered with since it was signed", in which case the data seen by the recipient is not the original data that the signer saw. Or, the result could be "The data was signed with a private/public key pair, where the public key does not match the public key used to test the signature". In this case the data was signed by someone else than the owner of the public key the recipient has. In both cases the signature is invalid.
It is not possible to simply use any public key that is found anywhere (or given by any one), because who would then guarantee that the public key received really is a key from the entity it supposedly belongs? The origin of the public key that is used to verify the digital signature of a certificate has to be very reliable, otherwise, the "man-in-the-middle" would still have a chance to spy. The intruder would create his own public/private keys with a forged name of "TrustCorp" and his own certificate with a forged host name of SomeCorp. Then he/she would use his/her own private key to sign the certificate and would give others the public key claiming, "This is the public key of TrustCorp". If this public key were used to check the validity of the forged certificate, a match would be made leading to the belief that the forged certificate is legitimate. As a result, the attacker would receive the communication and not the server of TrustCorp.
To verify a public key of the signing authority, most web-browsers, like Microsoft® Internet Explorer, are already equipped with a list of trusted so called "root certificates". It is not necessary to verify that these certificates indeed come from the entity they claim to, because the browser vendor has already verified this. The full trust-chain when a browser is used to access a secured is described below:
In the real life example, employees A and B both needed picture IDs to verify each other. With online communication this verification is often only one-sided. For most purposes it is enough that the client is certain about the server it communicates with. It is usually not required that the server is also certain about the client. Therefore, usually only the server has a certificate (which is, down the trust chain, signed by a trusted root certificate), and the client does not.
There are also real-word examples of this. If a car were purchased privately from its former owner, the buyer would most likely request to see a picture ID of the owner during the transaction. Otherwise he/she would risk unknowingly buying a stolen car. On the other hand, it is not a requirement for the former owner to see the buyer's ID.
To summarize the concepts introduced:
Server Certificate - This certificate asserts that a certain server (with the given host name) actually belongs to a certain organization, so that the server can be trusted and confidential data can be safely communicated. This certificate is digitally signed to prevent tampering and falsification.
Trusted Root Certificate - The trusted root certificate is used to sign the actual server certificate (or another certificate down the trust-chain is used to sign the actual server certificate). Usually the fact that a root certificate is installed together with trusted software (like the browser) already makes it a trusted root certificate. A root certificate can be received by other means (by e-mail, for example). In that case, first verify the certificate before it is rated as "trusted". To do this, compare the fingerprints on the sent and received certificates.
Encrypted Communication - This is made possible with the help of an encryption key, which is secretly generated when the communication first begins. Verifying that there is no "man-in-the-middle" while negotiating the encryption key is achieved by verifying the communication partner's certificate and matching its digital signature, to one of the trusted root certificates, further down the trust-chain.
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.
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:
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 website: http://java.sun.com/j2se/1.3/docs/tooldocs/win32/keytool.html
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. A keystore that contains trusted root certificates of some CAs (for example VeriSign and Thawte) follows with Java installation.
This keystore is initially protected with the default password "changeit", which should be changed immediately after the Java installation. If Java has been installed on a server and has not been in use for some time without utilizing the certificated (implying that the default password has not likely been changed), seriously consider either reinstalling Java or copying the default trusted root certificate keystore from a fresh installation, before changing its password, so that there is assurance that no one has tampered with the keystore and the certificates within.
To change the password of the default keystore, execute the following command:
Keytool -storepasswd -keystore KEYFILE
with the following replacement:
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 Java Runtime Environment installation directory, where it is found in the following location:
Firstly, the old password will be required (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!
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:
keytool -genkey -alias NAME -validity DAYS -keystore KEYFILE -keyalg RSA
with the following replacements:
NAME: The name of the certificate. Can be any name that is not already in use in the keystore file specified (see below), but choose an informative name that helps in recognition of the certificate at a later time.
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 to which the certificate shall be added. Can either be a relative or a full path name. If the file doesn't exist, it is created. If it already exists, a certificate with the given "NAME" is added to it.
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.
Be very careful with the keystore file into which 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.
At this point, the certificate has been created, but it is as yet unsigned.
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:
keytool -certreq -alias NAME -file OUTFILE -keystore KEYFILE
with the following replacements:
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 into which 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 in which 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:
Now submit this 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, it will first verify that the requester or his/her company is indeed genuine, i.e. if 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.
The signed certificate to be 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 into a file (usually "*.cer"). Then execute the following command:
keytool -import -alias NAME -file INFILE -keystore KEYFILE -trustcacerts
with the following replacements:
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.6 Installing a Trusted Root Certificate for more information.
Once the signed server certificate is imported into the keystore file, the LISTSERV® Maestro server needs to be aware of this certificate. This is the last step to securing the server. On the server to be secured with SSL, edit the file "server.xml" in the LISTSERV® Maestro installation folder:
\Program Files\L-Soft\Application Server\conf\server.xml
Near the end of the file there is a section labeled "HTTPS (SSL)". This section contains a connector for HTTPS connections, which is initially commented out (with braces "<!--" and "-->"). Remove the comment-braces around the connector, not around the explanatory comment-text that precedes the connector, to activate it:
It is also necessary to edit the values of the parameters "keystore" and "keypass", which currently contain only "TODO" comments:
As the value of "keystore", enter the absolute path to the keystore file (including drive letter), in which the signed certificate can be found. A relative path name cannot be used; the full path to the file must be supplied. The keystore file itself can be stored in any place that seems appropriate, but the "Application Server\commands" folder would be a good choice.
As the value of "keypass", enter the password that was used for the keystore (as explained earlier, the same password must also have been used). Security Issue: The password to the keystore and the certificate therein are included as plain text in this file. This can be a security breach, if unauthorized persons have access to this file. Therefore, employ the appropriate Windows security measures so that only authorized persons can access this file. This should previously have been done, as this file is integral to the functioning of the server. Tampering with this file, or other files in the "Application Server" folder, may prevent LISTSERV® Maestro from working.
The HTTPS-connector is pre-configured to use port 443, which is the standard port for HTTPS (in comparison to port 80, which is the standard port for normal HTTP). If this port cannot be used, then it is possible to change the port to any other value that is not in use on the server. However, in this case the users will have to enter a URL like "https://server.domain.com:yourPort/lui" instead, (just as with standard HTTP, if the standard HTTP port had been changed to something other than 80).
Finally, comment out or simply remove the normal HTTP connector in the "server.xml" file. Either simply delete it or enclose it in comment braces:
This is necessary so that the server is no longer accessible via normal HTTP. If this is not done, then users could use both HTTPS and HTTP URLs to access the server. As most users are not familiar with the HTTPS availability, most would probably default to the normal HTTP, and all communication would once again be unencrypted - which defeats the purpose of securing the server. Therefore, it is safer to remove/comment out the standard HTTP connector, to prevent users from accessing the server with normal HTTP and remind them to use HTTPS instead.
This also explains why it is not possible to secure a server that is running the Maestro Tracker component is running with SSL: 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, and HTTPS is too slow for this). As all components installed on one server share the same connectors, necessary to enable/disable a connector type for all components simultaneously. Therefore, if it is desirable to secure the Administration Hub and/or Maestro User Interface components with SSL, they must be installed on a separate server from the Maestro Tracker component (however, both components may be on the same server, as long as they both plan to be secured).
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:
keytool -import -alias NAME -file INFILE -keystore KEYFILE
with the following replacements:
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.
KEYFILE: The filename 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 Java Runtime Environment installation directory, where it is found in the following location:
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 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.