30.3 Securing HTTP Browser Connections

Using secure HTTP (HTTPS) improves the security of your Novell Teaming site. During installation, you can choose to configure your Teaming site for HTTP or HTTPS. After installation, you can force secure HTTP connections.

30.3.1 Preparing for Secure HTTP Connections

If you want users to access the Teaming site with a secure HTTP connection, you must configure Teaming with a root certificate and a server certificate. The root certificate identifies the root certificate authority (CA) for your Teaming site. The server certificate is customized for the specific server where Teaming is installed.

Understanding How Teaming Handles Certificates

Novell Teaming uses a keystore to store certificates. The default keystore file that is installed along with Teaming is:

Linux:

 
/opt/novell/teaming/apache-tomcat-version/conf/.keystore

Windows:

 
c:\Program Files\Novell\Teaming\
                              apache-tomcat-version\conf\.keystore

The original certificate in the default keystore is sufficient for you to set up secure HTTP connections during initial installation, but it is self-signed and expired, so you cannot use it permanently. Soon after installation, you must obtain a permanent certificate. You can use a commercially signed certificate or a self-signed certificate. There are advantages and disadvantages to each approach.

  • Commercially Signed Certificate: The advantage to using a certificate signed by a commercial certificate authority (CA) is that browsers automatically accept these certificates. The disadvantage is that an additional step is required, with some wait time while you obtain the commercially signed certificate.

  • Self-Signed Certificate: The advantage to using a self-signed certificate is that it is quick and easy for you to do as the Teaming administrator. The disadvantage is that users receive a warning in the browser about the self-signed certificate the first time they access the Teaming site using secure HTTP. Users must manually accept the self-signed certificate, then the warning never occurs again.

After you obtain your permanent certificate, you can store it in the default Teaming keystore, or in a location of your own choosing. Teaming reads the location of its keystore from the following file:

Linux:

 
/opt/novell/teaming/apache-tomcat-version/conf/server.xml

Windows:

 
c:\Program Files\Novell\Teaming\
                             apache-tomcat-version\conf\server.xml

If you do not want to use the default keystore location, you must update the server.xml file to match the location you choose for your keystore.

Creating a New Keystore File

You cannot update the Teaming .keystore file that is provided during installation. Instead, you must create a new .keystore file, then import your signed certificate into it.

  1. Create a new directory where you want to create the new .keystore file, such as a certs directory in a convenient location.

  2. Change to the new certs directory.

  3. Make sure that you can access the keytool tool:

    Linux:

    		 
    /usr/java/jdkversion/bin/keytool

    Windows:

    c:\Program Files\Java\jdkversion\bin\keytool.exe

    For convenient use, you might need to add its location to the PATH environment variable.

  4. Use the following command to create a new .keystore file:

    keytool -genkey -alias tomcat -keyalg RSA -keystore .keystore

  5. When prompted, specify a password for the new .keystore file, then confirm the password.

    IMPORTANT:The default password used by Tomcat is changeit. If you want to specify a password other than this, then you must also specify this password in the server.xml Tomcat configuration file, as described in Changing Your Password for the Keystore File.

    Do not forget the password you specify.

  6. When prompted for your first and last name, specify the fully qualified DNS name of the Teaming server, such as teaming.yourcompanyname.com.

    You are then prompted for additional information about your organization:

    • Organizational unit

    • Organization

    • City or locality

    • State or province

    • Two-letter country code

  7. (Conditional) If you are planning to obtain a your certificate from a commercial certificate authority (CA), respond to the additional information prompts with accurate information appropriate to your organization.

    or

    (Conditional) If you are planning to generate a self-signed certificate, press Enter to skip through the prompts.

  8. When prompted whether the information you provided is correct, enter yes.

  9. Press Enter to use the same password that you specified in Step 5 as the key password for Tomcat.

  10. List the files in the certs directory to see that a new .keystore file has been created.

Changing Your Password for the Keystore File

If you want to specify a password other than changeit for your .keystore file, as described in Step 5 in Creating a New Keystore File, then you must also specify this password in the server.xml Tomcat configuration file.

  1. Change to the following directory:

    Linux:

    		 
    /opt/novell/teaming/apache-tomcat/conf

    Windows:

    c:\Program Files\Novell\Teaming\apache-tomcat\conf

  2. Open the server.xml file in a text editor.

  3. Locate the keystorePass attribute, then change the value of this attribute to your new password.

  4. Save and close the server.xml file.

Generating a Certificate Signing Request

  1. Use the following command to create a Certificate Signing Request (CSR):

    keytool -certreq -alias tomcat -keyalg RSA 
        -file certreq.csr -keystore .keystore

  2. Enter the keystore password to create the CSR.

  3. List the files in the certs directory to see that a new certreq.csr file has been created along with the existing.keystore file.

  4. Use the certreq.csr file to obtain a signed certificate.:

    1. To use a commercial certificate authority (CA), continue with Submitting the Certificate Signing Request to a Certificate Authority (CA).

      or

    2. To use a self-signed certificate, skip to Using the Certificate Signing Request to Generate a Self-Signed Certificate.

Submitting the Certificate Signing Request to a Certificate Authority (CA)

You can find a commercial certificate authority (CA) on the Internet by searching for “certificate authority.” The process of obtaining a signed certificate varies from company to company. Each company provides instructions to assist you.

The certificate authority (CA) sends you a set of certificate files that you import into the Teaming keystore. You must import all of the files that you receive. Place the certificate files in a convenient location on the Teaming server, then skip to Importing the Certificate Files into the Teaming Keystore.

Using the Certificate Signing Request to Generate a Self-Signed Certificate

If you do not want to wait to receive your signed certificate from a commercial certificate authority (CA), you can generate your own self-signed certificate using ConsoleOne® or iManager. You must generate both a self-signed eDirectory™ root certificate file and a server certificate file.

NOTE:For iManager instructions, see TID 7001857: Adding SSL Certificates to Teaming for HTTPS in the Novell Support Knowledgebase. If you are using Active Directory rather than eDirectory, consult your Active Directory documentation for a procedure comparable to the one provided in Using the Certificate Signing Request to Generate a Self-Signed Certificate.

Generating a Self-Signed Root Certificate File in ConsoleOne

A root certificate identifies the root certificate authority (CA) for your Teaming site. In this case, eDirectory is acting as the root certificate authority.

  1. On Linux or Windows, start ConsoleOne and authenticate to your eDirectory tree.

  2. Expand the Security container, right-click the Tree_Name CA object, then click Properties.

  3. Click Certificates > Self Signed Certificate.

  4. Click Validate to update the certificate status, then click OK to close the Certificate Validation dialog box.

  5. Click Export to export your eDirectory root certificate into a file that can be imported into the Teaming keystore file.

  6. Click Next to accept the default of No for exporting a private key file along with the root certificate.

  7. Select the output format for the root certificate file.

    Either DER or Base64 format can be imported into the Teaming keystore file.

  8. In the Filename field, specify the location (the certs directory where you created the Certificate Signing Request) and the filename to use, such as SelfSignedRootCert.der.

  9. Click Next to display a summary of the options you have selected, then click Finish to generate the root certificate file.

  10. Click Cancel to close the Self Signed Certificate properties page of the Tree_Name CA object.

  11. Continue with Generating a Self-Signed Server Certificate File in ConsoleOne

Generating a Self-Signed Server Certificate File in ConsoleOne

A server certificate is customized for the specific server where Teaming is installed.

  1. Click Tools > Issue Certificate.

  2. Browse to and select the certreq.csr file that you created in the certs directory, then click Next.

    This retrieves the contents of the CSR file into the CSR window.

  3. Click Next to accept the default of using an organization certificate authority.

  4. Select SSL or TLS as the type of server certificate that you need, then click Next.

  5. Select the validity period you want for the server certificate, then click Next.

  6. Review the information that you have provided, then click Finish.

  7. Select the output format for the server certificate file.

    Either DER or Base64 format can be imported into the Teaming keystore file.

  8. In the Filename field, specify the location (the certs directory where you created the Certificate Signing Request) and the filename to use, such as SelfSignedServerCert.der.

  9. Click Save to create the public-key certificate file.

  10. Exit ConsoleOne.

NOTE:For iManager instructions, see TID 7001857: Adding SSL Certificates to Teaming for HTTPS in the Novell Support Knowledgebase. If you are using Active Directory rather than eDirectory, consult your Active Directory documentation for a procedure comparable to the one provided in Using the Certificate Signing Request to Generate a Self-Signed Certificate.

Importing the Certificate Files into the Teaming Keystore

After you have obtained or generated a signed certificate, you must import the certificate files into the Teaming keystore. This section describes how to import the files associated with a self-signed certificate. The same procedure can be used to import certificate files received from a commercial certificate authority (CA).

  1. Change to the certs directory where you created the root certificate file and the server certificate file.

  2. Use the following command to import the root certificate file:

    keytool -import -keyalg RSA -keystore .keystore
        -file SelfSignedRootCert.der

  3. Enter the keystore password to add the root certificate to the Teaming keystore.

  4. Use the following command to import the server certificate file:

    keytool -import -alias tomcat -keyalg RSA -keystore .keystore
        -file SelfSignedServerCert.der

  5. Enter the keystore password to add the server certificate to the Teaming keystore.

The new .keystore file is now ready for permanent use in your Teaming system.

Replacing the Original Teaming Keystore File with Your Permanent Keystore File

  1. Change to the following directory on the Teaming server:

    Linux:

    		 
    /opt/novell/teaming/apache-tomcat-version/conf

    Windows:

    		 
    c:\Program Files\Novell\Teaming\
                             apache-tomcat-version\conf

  2. Rename the existing .keystore file to keystorebackup.

  3. Copy your new .keystore from the certs directory to the conf directory.

  4. Adjust the ownership and permissions of the new .keystore file to match those of the backed up keystore file.

  5. Restart Teaming so that Teaming rereads the updated keystore file.

30.3.2 Implementing Secure HTTP Connections

When you run the Novell Teaming Installation program, you can choose between non-secure and secure HTTP connections, as described in HTTP/HTTPS Ports in Basic Installation in the Novell Teaming 2.1 Installation Guide.

30.3.3 Forcing Secure HTTP Connections

With additional configuration, you can force users from a non-secure HTTP connection to a secure HTTPS connection.

Using Novell Access Manager to Force Secure HTTP Connections

With Novell Teaming, you can use Novell Access Manager to force secure HTTP connections. For more information, see Configuring Single Sign-On with Novell Access Manager in Advanced Installation and Reconfiguration in the Novell Teaming 2.1 Installation Guide.

Configuring Tomcat to Force Secure HTTP Connections

To reconfigure Tomcat, you must update two configuration files (both named web.xml) under two different directories (ssf and ssfs). The ssf directory name refers to SiteScape® Forum, a legacy product name. The ssf directory contains the main Teaming Web application that you use when you interact with your browser. The ssfs directory name refers to SiteScape File System. The ssfs directory contains the Teaming WebDAV application that you use to access files on a remote WebDAV server from the Teaming site.

  1. Log into the Teaming server with sufficient rights to edit the web.xml files (root on Linux, Administrator on Windows).

  2. Modify the web.xml file under the ssf directory:

    1. Change to the directory where the web.xml file is located.

      Linux:

      		 
      /opt/novell/teaming/apache-tomcat-version/
                                         webapps/ssf/WEB-INF

      Windows:

      		 
      c:\Program Files\Novell\Teaming\apache-tomcat-version\
                                         webapps\ssf\WEB-INF

    2. Make a backup copy of the web.xml file, then open the web.xml file in a text editor.

    3. Add the following security constraint at the bottom of the file, immediately above the </web-app> tag.

      <security-constraint>
  <web-resource-collection>
    <web-resource-name>Entire Application</web-resource-name>
    <url-pattern>/*</url-pattern>
  </web-resource-collection>
  <user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
  </user-data-constraint>
</security-constraint>

    4. (Conditional) If users access the Teaming site with Internet Explorer*, replace the following single line provided above:

       <url-pattern>/*</url-pattern>

      with the following set of lines:

        <!-- Patterns from web.xml.tmpl. -->
  <url-pattern>/a/*</url-pattern>
  <url-pattern>/ws/*</url-pattern>
  <url-pattern>/rss/*</url-pattern>
  <url-pattern>/atom/*</url-pattern>
  <!-- Patterns from subdirectories of webapps/ssf. -->
  <url-pattern>/applets/*</url-pattern>
  <url-pattern>/css/*</url-pattern>
  <url-pattern>/help/*</url-pattern>
  <url-pattern>/help_doc/*</url-pattern>
  <url-pattern>/i/*</url-pattern>
  <url-pattern>/images/*</url-pattern>
  <url-pattern>/js/*</url-pattern>

      For Internet Explorer, this list of URL patterns forces secure HTTP connections for everything except the /s/* pattern (document files with extensions such as .odt and .doc) and the /ical/* pattern (calendar .ics files).

    5. Save the modified web.xml file, then exit the text editor.

  3. Modify the web.xml file under the ssfs directory:

    1. Change to the directory where the web.xml file is located.

      Linux:

      		 
      /opt/novell/teaming/apache-tomcat-version/
                                       webapps/ssfs/WEB-INF

      Windows:

      		 
      c:\Program Files\Novell\Teaming\apache-tomcat-version\
                                       webapps\ssfs\WEB-INF

    2. Make a backup copy of the web.xml file, then open the web.xml file in a text editor.

    3. Add the following security constraint at the bottom of the file, immediately above the </web-app> tag.

      <security-constraint>
  <web-resource-collection>
    <web-resource-name>Entire Application</web-resource-name>
    <url-pattern>/*</url-pattern>
  </web-resource-collection>
  <user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
  </user-data-constraint>
</security-constraint>

    4. Save the modified web.xml file, then exit the text editor.

Adding the Apache Web Server to Force Secure HTTP Connections

You can set up the Apache* Web server to front your Novell Teaming site and use a meta refresh to redirect users to a secure URL.

  1. Install the Apache Web server on one server.

  2. Configure Apache to listen on port 80.

  3. Create an index.html file similar to the following example:

    <html>
<head>
  <meta http-equiv="refresh" content="0;url=https://teaming_url" />
  <title>Redirected to Secure Teaming</title>
</head>
<body>
  This page is used to redirect to the Secure Teaming server. If your 
  browser does not automatically redirect you in a few seconds, click 
  <a href="https://teaming_url">here</a> to go to the secure page.
</body>
</html>

  4. Replace teaming_url with the URL to your Teaming site.

  5. Place the index.html file in the document root directory of the Apache Web server.

    Linux:

    		 
    /srv/www/htdocs

    Windows:

    		 
    c:\Program Files\Apache Software Foundation\Apache2.2\htdocs

  6. Restart the Apache Web server.

30.3.4 Defaulting to Secure HTTP URLs in Teaming Links

Novell Teaming includes URLs to Teaming site locations in e-mail messages and notifications. By default, the URLs are formed with http rather than https. You can reconfigure Teaming to default to https for Teaming site URLs.

  1. Log into the Teaming server with sufficient rights to edit the ssf-ext.properties file (root on Linux, Administrator on Windows).

  2. Change to the following directory:

    Linux:

    		 
    /opt/novell/teaming/apache-tomcat-version/
                           webapps/ssf/WEB-INF/classes/config

    Windows:

    		 
    c:\Program Files\Novell\Teaming\apache-tomcat-version\
                           webapps\ssf\WEB-INF\classes/config

  3. Make a backup copy of the ssf-ext.properties file.

  4. Open the ssf-ext.properties file in a text editor.

  5. Locate the following lines:

    adapter.web.protocol=context-http
servlet.web.protocol=context-http
rss.web.protocol=context-http
ical.web.protocol=context-http
ssfs.web.protocol=context-http
simpleurl.web.protocol=context-http

  6. Change http to https.

    adapter.web.protocol=context-https
servlet.web.protocol=context-https
rss.web.protocol=context-https
ical.web.protocol=context-https
ssfs.web.protocol=context-https
simpleurl.web.protocol=context-https

  7. Save the ssf-ext.properties file, then exit the text editor

  8. Restart Teaming to put the change into effect.