Securing Access with HTTPS

Transcription

1 LISTSERV Maestro Admin Tech Doc 9 Securing Access with HTTPS November 19, 2014 L-Soft Sweden AB lsoft.com

2 This document is a LISTSERV Maestro Admin Tech Doc. Each admin tech doc documents a certain facet of the LISTERV Maestro administration on a technical level. This document is number 9 of the collection of admin tech docs and explains the topic Securing Access with HTTPS. Last updated for LISTSERV Maestro on November 19, The information in this document also applies to later LISTSERV Maestro versions, unless a newer version of the document supersedes it. Information in this document is subject to change without notice. Companies, names, and data used in examples herein are fictitious unless otherwise noted. L-Soft Sweden AB does not endorse or approve the use of any of the product names or trademarks appearing in this document. Permission is granted to copy this document, at no charge and in its entirety, provided that the copies are not used for commercial advantage, that the source is cited, and that the present copyright notice is included in all copies so that the recipients of such copies are equally bound to abide by the present conditions. Prior written permission is required for any commercial use of this document, in whole or in part, and for any partial reproduction of the contents of this document exceeding 50 lines of up to 80 characters, or equivalent. The title page, table of contents and index, if any, are not considered part of the document for the purposes of this copyright notice, and can be freely removed if present. Copyright , L-Soft Sweden AB All Rights Reserved Worldwide. LISTSERV is a registered trademark licensed to L-Soft international, Inc. L-SOFT and LMail are trademarks of L-Soft international, Inc. CataList and EASE are service marks of L-Soft international, Inc. All other trademarks, both marked and not marked, are the property of their respective owners. Some portions licensed from IBM are available at This product includes code licensed from RSA Security, Inc. This product includes software developed by the Apache Software Foundation ( All of L-Soft's manuals for LISTSERV are available in ASCII-text format via LISTSERV and in popular word-processing formats via ftp.lsoft.com. They are also available on the World Wide Web at the following URL: URL: L-Soft invites comment on its manuals. Please feel free to send your comments by to: MANUALS@LSOFT.COM

3 Table of Contents 1 Securing Access with HTTPS Introduction to Secure Communication Which Components should be secured? Obtaining and Installing a Server Certificate Securing the Trusted Root Certificate Keystore Creating an Unsigned Server Certificate Performing a Certificate Signing Request (CSR) Installing the Signed Server Certificate Installing a Trusted Root Certificate or Intermediate Certificates Making LISTSERV Maestro aware of the Server Certificate Securing a Server with Multiple Host Names Mixing HTTP and HTTPS Access on one Server (Mixed Mode) Redirecting from HTTP to HTTPs Supported SSL/TLS Ciphers Minimum TLS Protocol Version iii

4 1 Securing Access with HTTPS LISTSERV Maestro is accessed by the user with a web browser over the network, often even over unsecure networks like the internet itself. However, giving access to users from the internet exposes the risk of unauthorized access. LISTSERV Maestro uses password authentication as a first barrier against intruders. But on the internet, network traffic as such is a public affair: Anyone with the right knowledge and access to certain nodes in the network may listen in 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 himself with the same account. If you LISTSERV Maestro is accessed over the internet or an unsecure local network and security is of concern for you, you may therefore want to think about securing access to your 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. Web browsers do all support encrypted communication via the Secure Sockets Layer (SSL), using the HTTPS protocol to access web-pages, instead of the normal HTTP protocol. The following subchapters describe how you can configure your LISTSERV Maestro server(s) to use HTTPS. Also, since the topic of encryption, server certificates, trusted authorities etc. is quite complex, an introduction is given that helps you understand the concepts involved, so that you can execute the required steps on an informed basis. Note: Securing access with HTTPS as described in this chapter is a separate issue than authenticating and encrypting communication between the components of LISTSERV Maestro, even though the two have many similarities and can even be combined. If what you are looking for is actually to authenticate and encrypt the communication between the separate components of LISTSERV Maestro (and not the communication between the user and the Maestro User Interface or Administration Hub) then please see LMA Admin Tech Doc 5 Multi Server Installation instead. 2 Introduction to Secure Communication This subchapter shall give you a short introduction about the basics of secure communication. Please see the many publications about this topic for more details. Basically, for encrypted communication, the only thing that is required is, that both communication partners both 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 a bit more complex. After all, both partners (i.e. the browser and the server), which probably communicate with each other for the first time, do not have a common encryption key that is known only to them (or if you wanted to do this, you would have to give every server/browser combination in the world a unique encryption key, which is obviously impossible). LISTSERV Maestro Admin Tech Doc 9 1 Securing Access with HTTPS

5 So when the connection is first established, the two partners decide on the fly on an encryption key that is used for the rest of the communication (this is a simplified view of the matter, but it explains the basics). OK, let s assume that the two partners have decided what key to use, so they can now communicate in an encrypted manner. There still is a problem: How can the two partners be sure that they are 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? For example, the 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 the 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 and gives the information he received from B to the real employee A. Of course, on his way from the lobby to the bar and back, he made copies of the information he was carrying. At 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 server and client know of each other are their network addresses, which can be forged. So how is this solved? In real live, the two employees of A-Corp and B-Corp would probably simply 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 been told before. If the ID matches the person, they would know that they talk to whom they are supposed to talk to. But in doing so, they actually implicitly trust a third party that has not been involved yet: This is the agency that issued the picture ID. With accepting the ID, they trust this agency, that it has created the ID in such a way, that it is hard to forge and they also trust this agency, that it in turn verified that the person they issued the ID to really is the person he claims to be. If employee A would have tried to use his golf club picture ID for identification, then employee B would probably have rejected it as improper identification, because he wouldn t trust either that the clerk in A s golf club responsible for issuing the ID really did a thorough check of A s identity, or he didn t trust the security features of the ID (these days, anyone can create a nice looking picture ID with the help of a color laser printer). So instead he would probably request a proper ID like a passport or something similar. With online communication, the problem of identifying the communication partner is solved in a similar way: 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 really is the entity it claims to be. For example, a certificate could assert, that the server with the host name host.somecorp.com really is a server that belongs to SomeCorp, and that it is not a server of an impostor. But how are the problems of credibility (has the identity really been checked thoroughly before the certificate was issued?) and falsification (can the certificate be falsified or a false certificate be created?) solved? LISTSERV Maestro Admin Tech Doc 9 2 Securing Access with HTTPS

6 Simply falsifying a file that states, the server host.somecorp.com indeed is a server of the SomeCorp corporation would not be too hard for an impostor. So what happens is, that the certificate is digitally signed by a trustworthy authority, so that it now reads:, the server host.somecorp.com is a server of 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 no longer matches and the certificate is invalid. But a last problem remains: To test the validity of the signature, you require the public key of the signing authority (this is the public counterpart of the private key that the signing authority used to sign the original certificate with). Of course you cannot simply use any public key that you find anywhere (or are given by someone), because who would then guarantee that the public key you got really is a key from the entity it supposedly belongs to? You need to be very sure about the origin of the public key that you use to verify the digital signature of a certificate, otherwise, the man in the middle would still have a chance to spy on you: 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 would use his own private key to sign the certificate and would give the public key to you claiming this is the public key of TrustCorp. If you would then use this public key to check the validity of the forged certificate, you would get a match, e.g. you would believe the forged certificate that states that a certain host belongs to SomeCorp. While you believed that you communicated with a server of TrustCorp, you would instead be communicating with a server of the attacker. So how do you verify the public key of the signing authority? Luckily, when it comes to web-browser, in most cases you do not have to do this explicitly: Most web-browsers are already equipped with a list of trusted so called root certificates. You do not have to verify that these certificates indeed come from the entity they claim they come from, because the browser vendor has already done this for you. So the full trust-chain when you use your browser to access a secured server looks like this: The browser vendor received root certificates from the signing authorities, verifying their validity. You trust the browser vendor that it included only root certificates of entities whose identity he could confirm (and implicitly you also trust yourself, that you didn t install a browser from a 3 rd party that only claims to be the browser vendor you think it is, but instead is a front-end for an attacker who wants to give you falsified root certificates this way). Your browser trusts any certificate that is signed with a certificate that can be traced to one of the trusted root certificates (this can be a very short chain like a certificate signed with a root certificate or a long chain like a certificate signed with a certificate that was signed with a certificate etc. that was signed with a root certificate ). Your browser trusts any server that has a certificate that the browser trusts. In the real life example, we met the employees A and B who 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 sure about the server it communicates with. It is usually not required that the server is sure about the client too. LISTSERV Maestro Admin Tech Doc 9 3 Securing Access with HTTPS

7 Therefore, usually only the server has a certificate (which is, down the trust chain, signed by a trusted root certificate), but not the client. There are real-word examples for this too: If you buy a car privately from its former owner, then you probably want to see a proper picture ID of that owner, to make sure that he matches the picture in the ID, and the name and address on the ID match the ones in the documents of the car. Otherwise you would risk buying a stolen car without knowing it. On the other hand, the seller does not necessarily have to see your ID, because he really doesn t care about who you are (as long as you pay cash, of course ). Finally, lets summarize the concepts we have introduced: Server Certificate This certificate asserts, that a certain server (with the given host name) really belongs to a certain organization, so that you can trust the server and safely communicate confidential data to it. This certificate is digitally signed to prevent tampering and falsification. Trusted Root Certificate The trusted root certificate was used to sign the actual server certificate (or another certificate down the trust-chain that was used to sign the actual server certificate, etc.). Usually the fact that a root certificate is installed together with a trusted software (like the browser) already makes it a trusted root certificate. Sometimes you would also receive a root certificate via other means (for example via ). In that case you would first have to verify it before you can rate it as trusted. For example, you could call the person that sent you the certificate and let her read the certificate s fingerprint to you, which you could compare to the fingerprint of the certificate you received. Encrypted Communication Happens with the help of an encryption key which is generated on the fly when the communication begins. The verification that you are not talking to some man-in-themiddle while negotiating the encryption key happens through verifying the communication partner s certificate and matching its digital signature (down the trust-chain) to one of the trusted root certificates. 3 Which Components should be secured? Normally, you should only secure the Maestro User Interface and/or the Administration Hub component with HTTPS, not the Maestro Tracker component. Because securing the Maestro Tracker component has several drawbacks: HTTPS is slower and takes more system resources than HTTP, so if you have a high tracking event volume, then using HTTPS puts a higher workload on the Tracker server. Also not all clients may be able to access HTTPS-URLs correctly, which could result in tracking events not being counted and recipients not being redirected to the intended target pages (in case of click tracking). Before you decide to also secure Maestro Tracker, you should take these possible drawbacks into account and evaluate, if they are worth the additional security gain in your situation. Additional preparations need to be made if you have several components installed on the same server, but only want to secure some of them. For example if you have all three components on the same server, but only want to secure LUI and HUB, but not TRK (which is recommended, as explained above). In such a case, you need to have at least two separate IP-addresses for the server, each with a separate host name. You would then use one host name and IP-address pair for the components that are to be secured (LUI/HUB) and the other pair for the components that are not to be secured (TRK). LISTSERV Maestro Admin Tech Doc 9 4 Securing Access with HTTPS

8 4 Obtaining and Installing a Server Certificate To make LISTSERV Maestro able to use HTTPS, you need to obtain a signed server certificate for the server you want to secure. You cannot simply obtain any server certificate and use it on a server of your choice: The certificate is always bound to the explicit server name that you chose when you created the certificate. Should you want to move your LISTSERV Maestro component to a different server (with a different name) or want to rename your server, then you would have to obtain a new certificate for the new name. Obtaining a server certificate involves three basic steps, which are explained in more detail in the following subchapters: Create an unsigned certificate with the name of the server you want to secure. Create a certificate signing request (CSR) from that certificate and send it to a certification authority (CA). The CA first verifies that you really are who you claim to be and then returns a signed version of your certificate to you. Replace the unsigned certificate with the signed certificate you got back from the CA. The administration of the certificates 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 documentation of this tool at Oracle s website: and Securing the Trusted Root Certificate Keystore As a first step when starting to use certificates, you should secure the default keystore for trusted root certificates that is shipped with LISTSERV Maestro. This keystore already contains trusted root certificates of many CAs. This keystore is initially protected with the default password changeit, and you should change this password as soon as you can after installation of LISTSERV Maestro. To change the password of the default keystore, execute the following command: [maestro_install_folder]/java/bin/keytool storepasswd keystore [maestro_install_folder]/java/lib/security/cacerts You are first queried for the old password (which is changeit if it has not been changed since installation of LISTSERV Maestro), and then twice for the new password. You need to enter a new password with at least six characters, but longer and complex passwords are safer! LISTSERV Maestro Admin Tech Doc 9 5 Securing Access with HTTPS

9 4.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 create a new certificate in a keystore file, execute the following command: [maestro_install_folder]/java/bin/keytool genkeypair alias NAME validity DAYS -keystore KEYFILE keyalg RSA keysize 2048 with the following replacements: NAME: The name of the certificate. Can be any name that is not already in use in the keystore file you specify (see below), but you should choose an informative name that helps you recognize the certificate at a later time. DAYS: Limits the validity of the certificate. The certificate will expire so many days after the day when you created it. Can be any number of days. Usually, when you purchase the signing service from the CA, you pay for only a limited period during which the certificate shall be valid. Choose a number of days for this parameter, that is no shorter than the period you purchase from the CA (a little padding here is probably a good idea, to be on the safe side). 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. Note: This is not the same keystore file as the default keystore file that was used in section 4.1, but is a different keystore, in which you store your server certificate. Choose a suitable location and filename for your keystore file, that takes into account the special security considerations for this file (see below). Note about the keysize parameter: The command line as shown above specifies a key size of 2048 bits, which conforms to the current recommended standard. You should only specify a shorter key if there is a good reason for this. If the certification authority that you are planning to use to later certify and sign your certificate (see section 4.3) allows larger key sizes (for example 4096 bits), then you may want to change this parameter to a larger value. Important: Be very careful with the keystore file into which you create the certificate. You need to protect this file in several respects: Do not lose or accidentally delete this file, since it contains your certificates and you would have to purchase new certificates if you lose this file. You should always keep a backup at a safe location. This backup location should be outside of your LISTSERV Maestro installation folder, or otherwise the files could be deleted during an uninstallation of LISTSERV Maestro. Protect the file against unauthorized access. Even though the file is password protected, passwords can always be cracked, and an attacker could thus gain access to your certificates. The tool first prompts you to enter the password with which the keystore is protected. If you are using an existing keystore, you need to enter its password. If you gave a filename of a keystore that does not yet exist, then a new keystore is created and it is protected with the password you enter at the first prompt (you must choose a password with at least six characters, but longer and complex passwords are safer). LISTSERV Maestro Admin Tech Doc 9 6 Securing Access with HTTPS

10 Next, the tool prompts you for the following information values. Each time you may press RETURN to simply accept the default value Unknown. However, some values you must enter for the certificate to work and some CAs require that you fill out other values. So it is generally a good idea to fill out all values with whatever fits bets in your case (see below): What is your first and last name? Here you must enter the host name of the server that you want to secure with the certificate you are creating., even though the question asks after your first and last name, you have to enter the host name of the computer instead! This should be the same host name that is used in the URLs to access the server. For example, if the URL is then you need to enter the host name maestro.mycorp.com (without the quotes, of course). 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? Here you should use the two-letter uppercase code that fits the country where the server is deployed, like US, DE, SE, CH, etc. When you have answered the last question, you see a summary of your input and are requested to confirm it. Type yes and RETURN to accept your input, or no and RETURN (or simply RETURN) to reject it (in this case you can enter the values again, until you are satisfied). After you have confirmed your input, the tool generates the certificate. When it is done, it asks you for a password to protected the certificate. Although generally you are able to choose any password, for the certificate to be usable with LISTSERV Maestro, you must enter the same password as you chose for the keystore itself. To do so, simply press RETURN without entering anything, so that you accept the default. Now the certificate is created, but it is still unsigned. 4.3 Performing a Certificate Signing Request (CSR) Once you have created an unsigned certificate, you can generate a certificate signing request (CSR) from it, that you can submit to a certification authority (CA) of your choice, for example VeriSign. To generate a CSR for a certificate in the keystore, execute the following command: [maestro_install_folder]/java/bin/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 you want to create the CSR for (the same name that you specified when you created the certificate). LISTSERV Maestro Admin Tech Doc 9 7 Securing Access with HTTPS

11 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 queries you for the password of the keystore. After you have entered it, the file you specified as OUTFILE will be written. This file is a text file that contains the CSR in Base64-encoded form. It will look similar to this: -----BEGIN NEW CERTIFICATE REQUEST----- tpnjhslouocsbyamym11qiz5bevwanjfz6kyn/xft5nfxgiy9uynz5kodfbwfugiu98iqkwymkc/ bgfuz2vumq8wdqydvqqkewzmlvnvznqxedaobgnvbastb1vua25vd24xdzanbgnvbamtbnrlchbp 6E7Zyl9wkPyVpn1qbnbtXQGAablJInE9/LruaJ1NX1f/NVJgL4vPiDKsU4laGvJHBNhdj+F0uVb3 SIb3DQEBBAUAA4GBAB6XqdfJvhy7dTHijsHjw+c4ELQFI/TkHBvgp5NaCccQoNwwW9lnIeOikDb2 lwwg56g6liyfpvbss5+oow2jxlq9cdnw1klsdq+kmtzjdvr8+iq9gsqxvskcaweaaaaama0gcsqg MIIBpjCCAQ8CAQAwZjELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0dlcm1hbnkxETAPBgNVBAcTCEVy YzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAz+hQRsqDWRLvmV4YD5+JaQEXn5qqJeyzkfg2 PQoU2VPgHID0VnyTPt8r/t4uFk8p1NxjYkC END NEW CERTIFICATE REQUEST----- You now have to submit this CSR to the CA of your choice which is usually possible online. After the CA has received your CSR, they will first verify that you (or your corporation) indeed are who you claim to be, i.e. if the content of the certificate can be trusted or not. This usually happens via conventional means (making phone calls, checking company registrations, etc.) and may take a few days. Once they have verified the validity of the certificate, they will either return the signed certificate to you, or will supply you with further instructions on how to obtain it. 4.4 Installing the Signed Server Certificate The signed certificate that you receive back from your CA must be in X.509 format (v1, v2 or v3), either in binary or Base64 encoded form, or in a PKCS#7 formatted certificate chain file consisting of certificates in the same X.509 format (please contact your CA if the certificate you received doesn t match either of these formats). Once you have received the signed certificate (or certificate chain), store it into a file. Then execute the following command: [maestro_install_folder]/java/bin/keytool importcert 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 you made the CSR for (the same name that you specified when you created the certificate and the CSR). INFILE: The file in which you have stored the reply from the CA that contains your signed certificate or certificate chain. KEYFILE: The keystore file in which the certificate is stored. Can either be a relative or a full path name. LISTSERV Maestro Admin Tech Doc 9 8 Securing Access with HTTPS

12 The command loads the certificate from the given file and tries to validate it using the available trusted certificates in your keystore and in LISTSERV Maestro s trusted root certificate keystore. If a trust chain can be established, starting at the imported certificate and ending at a self-signed certificate that belongs to a root CA, then the signed certificate is imported into the keystore, and thus replaces the unsigned version of the certificate that was in the keystore before. You have now successfully installed a signed certificate for your server. In this case you can skip the following subsection. If such a trust chain cannot be established, an error message is printed out and the signed certificate is not imported. In this case, proceed as described in the following sub-section Installing a Trusted Root Certificate or Intermediate Certificates This step is only required if you attempted to import the signed certificate into your keystore, as described in the previous section, but received an error message that a valid trust chain to a root CA certificate could not be established. This can happen in two situations: Case 1: The signed certificate was signed by a CA for which LISTSERV Maestro includes a trusted root certificate, but it was not signed directly with this trusted root certificate, but instead it was signed with one or several intermediate certificates, thus building a certificate chain, and only the last of these certificates was signed with a known trusted root certificate. In this case, you need to obtain all the necessary intermediate certificates too. Then import each of them into your keystore file too, starting with the lowest certificate in the chain, i.e. the one furthest removed from your own certificate. For this import, use the same command as described in the previous section, only for the -alias parameter (i.e. as a replacement for NAME), specify a certificate alias that is not already in use in the keystore. Chose a meaningful alias that allows you to recognize the intermediate certificate at a later time. If during the import of an intermediate certificate you get the message that the certificate is already in the keystore, then you do not have to import it again. Select No when prompted to replace the existing certificate. Or if you get a message that prints out the certificate details and fingerprint and asks you if you trust this certificate, then this means that you have not yet obtained all the necessary intermediate certificates that build the full certificate chain down to the trusted root certificate. Or you have tried to import the certificates in the wrong order. In both cases, answer no when queried if you trust the certificate (i.e. do not trust the certificate at this point). Instead, make sure that you really have all intermediate certificates that are required and make sure that you import them from the bottom up, i.e. start with the intermediate certificate that is removed furthest from your own certificate, then import the next higher certificate, and so on. Once you have imported all intermediate certificates, go back to the step described in the previous section and again try to import the signed certificate that you received from your CA. If you did indeed import all necessary intermediate certificates, then this time the import should succeed. Case 2: The signed certificate was signed by a CA for which LISTSERV Maestro does not include a trusted root certificate. In this case, you first need to obtain the actual self-signed root certificate of your CA. Be very careful that you really get the correct certificate! LISTSERV Maestro Admin Tech Doc 9 9 Securing Access with HTTPS

13 Then import this certificate into your keystore, using the same command as described in the previous section, only for the -alias parameter (i.e. as a replacement for NAME), specify a certificate alias that is not already in use in the keystore. Chose a meaningful alias that allows you to recognize the root certificate at a later time. You then get a message that prints out the certificate details and the certificate fingerprint and asks you if you trust this root certificate. You should now carefully compare the displayed certificate fingerprint with the fingerprint of the CA s root certificate. Make sure that the fingerprint matches. If it does, answer yes to import the certificate. After you have imported the new trusted root certificate into your keystore, you may also have to import additional intermediate certificates, as described in the previous bullet. Once you have imported all intermediate certificates (if any), go back to the step described in the previous section and again try to import the signed certificate that you received from your CA. If you did indeed import the correct self-signed root certificate of your CA and all necessary intermediate certificates, then this time the import should succeed. 5 Making LISTSERV Maestro aware of the Server Certificate Once you have imported the signed server certificate into your keystore file, you now need to make the LISTSERV Maestro server aware of this certificate, as a last step of securing your server. On the server that you want to secure with HTTPS, edit the file tomcat.ini : [maestro_install_folder]/conf/tomcat.ini To enable HTTPS, you need to add a SecureServer entry with the value of true, like this: SecureServer=true Setting this entry to true has the effect that HTTPS is enabled on all addresses that LISTSERV Maestro binds to (all addresses are secured). Setting this entry to false" or not specifying the entry at all has the effect that HTTPS is disabled on all bound addresses (in which case the following description does not apply either). Reminder: You can configure which addresses LISTSERV Maestro shall bind to (either all addresses or only a subset) via the BindAddress entry. See LMA Admin Tech Doc 6 IP Addresses and Ports for details. In addition to enabling HTTPS as described above, you also need to specify the information about the keystore file in which the server certificate is stored. You do so with the following two entries: KeystoreFile=KEYSTORE_PATH KeystorePassword=PASSWORD with the following replacements: KEYSTORE_PATH : Replace with the absolute path to the keystore file (on Windows including drive letter) in which the signed certificate can be found. You cannot use a relative path name but must supply the full path to the file. You can store the keystore file itself in any place that seems appropriate, but the [maestro_install_folder]/conf folder seems like a good choice. LISTSERV Maestro Admin Tech Doc 9 10 Securing Access with HTTPS

14 PASSWORD : Replace with the password that you used for the keystore (as explained earlier, you must have used the same password for the certificate itself too). Security Issue: As you see, the password to the keystore and the certificate therein is included as plain text in this file. This can be a security breach, if unauthorized persons have access to this file. You should therefore employ the appropriate operating system or file system security measures, so that only authorized persons can access the tomcat.ini file (since it is a file integral to the functioning of the server, you should have done this anyway, because tampering with this file, or other files in the installation folder, may stop LISTSERV Maestro from working properly). LISTSERV Maestro automatically uses the first applicable certificate that it finds in the specified keystore. If you have several applicable certificates in the keystore, for example old expired versions and a new current version of the same certificate, and you want to make sure that LISTSERV Maestro picks the correct certificate, you can also specify the certificate alias: CertificateAlias=ALIAS where you replace ALIAS with the keystore alias of the certificate that is to be used. You may also have to edit the SecurePort entry in the same tomcat.ini file. This entry specifies the port to be used for receiving client requests when using the HTTPS protocol. If this entry is not specified, the default HTTPS-port 443 is used. If the SecurePort entry is specified, it overrides this default behavior. Therefore, once you have enabled HTTPS, check if the SecurePort entry matches the now enabled HTTPS protocol: If a SecurePort entry is present, does it specify the correct port you want to use? If not, either remove the entry (to use the default port 443) or change its value to your desired port. If you do change the SecurePort entry, please see also LMA Admin Tech Doc 6 IP Addresses and Ports about other issues that apply when changing ports (for example adjusting certain HUB settings). If LISTSERV Maestro binds to all addresses, then this SecurePort is used for all addresses. If you have configured the BindAddress entry to bind only to some addresses, then any bind addresses that specify their own port in the BindAddress entry use this specific port, regardless of the SecurePort entry, and only bind addresses that do not specify their own port use the port from the SecurePort entry. LISTSERV Maestro is now prepared for HTTPS access. Start (or restart) LISTSERV Maestro to make the changes effective. You can access LISTSERV Maestro normally, only now you need to use https: URLs instead of the standard because once you have enabled and configured HTTPS access as described above, the communication with all components on this server may now only happen via HTTPS anymore. Normal access to this server via HTTP is no longer possible. Note: The above procedure describes what you need to do if you want to secure the whole server with HTTPS, i.e. all components that are installed on that server. If instead you only want to secure some components, then see section 7 Mixing HTTP and HTTPS Access on one Server (Mixed Mode) for details of how to configure such a mixed mode. LISTSERV Maestro Admin Tech Doc 9 11 Securing Access with HTTPS

15 6 Securing a Server with Multiple Host Names Under normal circumstances, HTTPS does not work if the server has several different host names, which are mapped to the same IP-address. This is a technical limitation of HTTPS, not a specific limitation of LISTSERV Maestro. If you have such a server with multiple host names and still want to secure it with HTTPS, you need to assign several IP-addresses to the server so that each host name can have its own dedicated IPaddress, i.e. each IP-address that is assigned to the server must be used by only one of the server s host names. Then you can create and install certificates for all these host names, and the individual IP-addresses make sure, that for each HTTPS request that is directed to one of the host names, the correct certificate that matches the IP-address of that host name is selected. How you do this depends on your scenario: If you have multiple host names for the server, but want to HTTPS -secure the server for all these host names (and for all Maestro components), then you do this in the same fashion as described in the previous sub-sections, only that you need to have a separate IP-address for each host name, and you need to obtain a separate server certificate for each host name too, where you store all these server certificates in the same keystore file. But if you want to HTTPS -secure only some of the host names and leave some unsecured, then you need to run the server in mixed mode, where you HTTPS -secure access to some of these IPaddresses, but not to others (see section 7 Mixing HTTP and HTTPS Access on one Server (Mixed Mode) for details). 7 Mixing HTTP and HTTPS Access on one Server (Mixed Mode) The requirement for running the LISTSERV Maestro server in mixed mode (partially HTTPS-secured and partially not) can arise from several scenarios: If there are several components installed on the server (for example all three) but only some of them are supposed to be HTTPS-secured (for example LUI/HUB) but others are not (for example TRK). If the server has several host names, and only some of them shall but HTTPS-secured but others not. Any mix of the two scenarios above. For example: A server with several host names, some of which shall be HTTPS-secured and some not, and even for the HTTPS-secured host names, only some of the installed LISTSERV Maestro components shall be secured but others not. There are a few pre-conditions for configuring HTTP/ HTTPS mixed mode: If you want to HTTPS-secure some host names, but not others, then for each host name that you want to secure, you need a separate IP-address. This means that this IP-address must only be used by this one host name. Neither is a secured host name allowed to share an IPaddress with another secured host name, nor is it allowed to share an IP-address with one of the unsecured host names (but the unsecured host names may share one IP-address among them). LISTSERV Maestro Admin Tech Doc 9 12 Securing Access with HTTPS

16 For example: Assume that you have five host names, of which two shall be secured and three not, then you need at minimum three IP-addresses: One to be used solely by the first secured host name, a second IP-address to be used solely by the second secured host name, and a third IP-address to be shared by the three unsecured host names. If you want to secure some of the installed LISTSERV Maestro components but not others, then you need at least two host names with unique IP-addresses: One of these host name/ip-address pairs would be used for the components that are to be secured, the other pair for the components that are not be secured. For example: Assume that you have LUI, HUB and TRK on the same server and want to secure LUI and HUB, but not TRK. You need two host names with two unique IP-addresses: One pair to be used by LUI/HUB (secured) and one pair to be used by TRK (unsecured). Depending on your scenario and according to the above pre-conditions you will therefore have a list of host names that you want to secure, each of which must have a unique IP-address that is not used by any other host name. In the description below, we will call these the secured host names and secured IP-addresses. With these secured host names and secured IP-addresses, you can then configure the HTTP/ HTTPS mixed mode more or less in the same fashion as when securing the whole server (as described in the previous sub-sections), except for the following differences: In the tomcat.ini, instead of supplying SecureServer=true (as you would if you wanted to secure the whole server), you now supply a comma-separated list of all the secured IP-addresses, like this: For example: SecureServer=SECURED_IP_ADDRESS1,SECURED_IP_ADDRESS2,... SecureServer= , , You can specify both IPv4 and IPv6 addresses (also mixed), but IPv6 addresses must be enclosed in brackets [ and ]. Each address can also specify an individual port (see below). Of all the addresses that LISTSERV Maestro binds to, all addresses that appear in this SecureServer entry are secured, all other addresses remain unsecure. If the SecureServer entry contains an address that LISTSERV Maestro does not actually bind to, then this address is ignored. Or in other words: If an address is not bound at all, it does not make sense to secure it either. Reminder: You can configure which addresses LISTSERV Maestro shall bind to (either all addresses or only a subset) via the BindAddress entry. See Admin Tech Doc 6 IP Addresses and Ports for details. Which HTTPS port is used? Every secured address listed in the SecureServer entry that includes a port value will use this port. An IPv4 address with port is specified as address:port, an IPv6 address with port is specified as [address]:port. For all addresses in the SecureServer entry that do not specify a port, LISTSERV Maestro first checks the BindAddress entry. If the address is listed here with a specific port, then this port is used. If not, then the port that is specified by the SecurePort setting is used. If this setting is not present, the default port 443 is used. Obtain a server certificate for each of the secured host names, but do not store these server certificates in one and the same keystore file. Instead, you need to have a separate keystore file for each certificate. I.e. you need one separate keystore file for each secured host name, containing the certificate for that host name. LISTSERV Maestro Admin Tech Doc 9 13 Securing Access with HTTPS

17 These keystore files must all observe the following constraints: All keystore files must use the same password. This is also the password that is you need to specify in the tomcat.ini as the value of the KeystorePassword setting. All keystore files must use the same keystore type (as specified by the advanced tomcat.ini setting KeystoreType ). All keystore files must be stored in the same folder. All keystore files must be named according to the following naming pattern: IP_ADDRESS-COMMON_FILENAME where IP_ADDRESS is the secured IP-address that corresponds to the secured host name to which the keystore file belongs: For an IPv4 address, specify the address in the form and for an IPv6 address, specify the address in the form aa00-bb11- cc22-dd33-ee44-ff55-aa66-bb77, i.e. in hex-notation, without 0-block abbreviations but using a single 0 for a 0-block, and with dashes - instead of the usual colons :. Also, COMMON_FILENAME is a freely selectable file name, which however must be the same for all keystore files. For example, let s assume we have three keystore files for secured host names with two secured IPv4 addresses and , and one secured IPv6 address fe80::7026:d336:94f8:74c7. And for the common file name we chose certificate.keystore. Then we would have to create three keystore files with the following full file names: certificate.keystore certificate.keystore fe d336-94f8-74c7-certificate.keystore For the KeystoreFile setting in the tomcat.ini, supply the following value: KeystoreFile=PATH_TO_FOLDER_OF_KEYSTORE_FILES/COMMON_FILENAME So for our example of above, assuming that the keystore files are stored in a folder called C:/Maestro/conf, the entry would look like this: KeystoreFile=C:/Maestro/conf/certificate.keystore Note, that you specify only a single KeystoreFile entry in the tomcat.ini, even though there are several keystore files! When specifying this entry, you supply only the path and the common filename. LISTSERV Maestro then automatically generates the actual keystore filenames from this setting by inserting each secured IP-address (with the separating - character) between the path and the common file name part. So for each secured IP-address, the actual filename will become something like: C:/Maestro/conf/ certificate.keystore which then matches the file names that we gave our keystore files (see above). Again, LISTSERV Maestro always picks the first applicable certificate for each host name that it finds in each keystore. If you have several applicable certificates in a keystore, for example old expired versions and a new current version of the same certificate, and you want to make sure that LISTSERV Maestro picks the correct certificate, you can also specify the certificate alias: LISTSERV Maestro Admin Tech Doc 9 14 Securing Access with HTTPS

18 CertficateAlias=IP_ADDRESS_1#ALIAS_1,IP_ADDRESS_2#ALIAS2,... In this case, the value of the CertificateAlias setting is a comma-separated list of IP-address/alias pairs. In each pair, the IP-address comes first and the alias second, separated by a # (and the alias name must not contain a comma). For each IP-address that is listed in the SecureServer setting as a to-be-secured address, LISTSERV Maestro looks up the same address in the CertificateAlias setting. If an IP-address/alias pair is found for a given address, then the alias from this pair is used as the certificate alias for the keystore of this IP-address. In order that this matching between the IP-addresses in the SecureServer and CertificateAlias settings works correctly, make sure to type the addresses in exactly the same way, in both locations. Finally, check the URL Settings in the HUB (on default level and/or group or user level), to check that the protocol, hostname and port that is specified there matches your HTTP/ HTTPS configuration: Access URLs to secured host names must use while access URLs to unsecured host names must use 8 Redirecting from HTTP to HTTPs No matter if you secure all addresses that LISTSERV Maestro binds to (with SecureServer=true ) or only some of the addresses (by specifying a list of addresses in the SecureServer entry), the result is always, that on all secured addresses, LISTSERV Maestro will now only accept access with the secure HTTPS protocol, on the specified secure HTTPS port(s). This means that if a user mistakenly tries to access LISTSERV Maestro with the normal HTTP protocol in the URL, then this user will not be able to make a connection. This may be the desired behavior, but in many situations this is not desired, because users are prone to forget the additional s in the protocol when they enter the access URL. And then they get confused that they are unable to access LISTSERV Maestro, as they do not realize their small mistake. This is true especially in situations where LISTSERV Maestro used to be accessed with the normal HTTP protocol and was only recently switched to the secure HTTPS protocol, and now all old HTTP bookmarks that the users may still have suddenly cease to function. To avoid this kind of confusion, you can configure LISTERV Maestro to also accept normal HTTP requests, on the normal HTTP port(s), and automatically redirect these requests to use the HTTPS protocol instead. You do this by adding the following entry to the tomcat.ini file: HttpToHttpsAutoRedirect=IP_ADDRESS_LIST where IP_ADDRESS_LIST must be replaced with a comma separated list of IP-addresses. You can specify both IPv4 and/or IPv6 addresses. Each IP-address can optionally also specify a port. An IPv4 address with port is specified as address:port, an IPv6 address with port is specified as [address]:port. If no port is specified for an address, the default HTTP port as defined by the Port entry will be assumed. LISTSERV Maestro then accepts normal HTTP connections on each address/port combination in this list but redirects each HTTP request that it receives on them and converts it into a HTTPS request that goes to the same IP-address but with the secure HTTPS port that was configured for this address. In this list of addresses, you can also use the keyword all instead of an IP-address, either with or without a specific port (the latter separated with a colon : ). This has the effect that LISTSERV LISTSERV Maestro Admin Tech Doc 9 15 Securing Access with HTTPS

19 Maestro accepts normal HTTP connections on all secured addresses (on the given port). I.e. the keyword is a shortcut for spelling out all secured addresses explicitly. Examples: HttpToHttpsAutoRedirect=all In addition to accepting secure HTTPS requests, LISTSERV Maestro will now also accept normal HTTP requests on all secured IP-addresses, using the default HTTP port as configured by the Port entry, and will redirect these HTTP requests to HTTPS. HttpToHttpsAutoRedirect=all,all:8080 Same as before, but HTTP requests on all secured IP-addresses will now be accepted both on the default HTTP port as configured by the Port entry and on the specific port HttpToHttpsAutoRedirect= , Same as the first example, but HTTP requests (on the default HTTP port) will not be accepted on all secured IP-addresses, but only on the two addresses specified. HttpToHttpsAutoRedirect= , :8080, Same as the previous example, but now the IP-address will accept HTTP requests both on the default HTTP port and the explicitly specified port HttpToHttpsAutoRedirect=all, :8081, :8082 HTTP request are now accepted on all secured IP-addresses with the default HTTP port and on address additionally with port 8081 and on address additionally with port Note: If you specify an IP-address that is not actually secured with HTTPs or not even bound at all, then this address will be ignored. Similarly, if you specify an address with a port where the same port is already in use as the secure HTTPS port on this IP-address, then this address/port combination will be ignored. 9 Supported SSL/TLS Ciphers The SSLCiphers entry in the tomcat.ini file defines the list of ciphers that the LISTSERV Maestro server supports for HTTPS connections. Connecting clients must use one of these ciphers to be able to connect via HTTPS. The value for this entry is a comma separated list that can contain the alias DefaultStandard and/or the alias DefaultStrong and/or any of the individual cipher names as listed in the two tables below, in any combination. I.e. the two aliases can also be combined with each other or with any of the cipher names. The alias DefaultStandard stands for all ciphers that are shown as included in alias DefaultStandard in the first table below. Similarly, the alias DefaultStrong stands for all ciphers that are shown as included in alias DefaultStrong in the second table below. If left out, the SSLCiphers entry defaults to SSLCiphers=DefaultStrong,DefaultStandard. LISTSERV Maestro Admin Tech Doc 9 16 Securing Access with HTTPS

20 The following low and standard strength ciphers (up to 168-bit) are supported by LISTSERV Maestro: Cipher Name: SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_DES_CBC_SHA SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA SSL_DH_anon_WITH_RC4_128_MD5 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA256 TLS_DH_anon_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_NULL_SHA TLS_ECDHE_ECDSA_WITH_RC4_128_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA Included in alias DefaultStandard LISTSERV Maestro Admin Tech Doc 9 17 Securing Access with HTTPS