Each Sametime 8.5.2 WebSphere Application Server V7.0 component supports TLS/SSL encryption out of the box using self-signed SSL certificates. In a production environment, it is recommended to install SSL certificates from a trusted Certificate Authority.  This article will define the configuration to install third-party SSL certificates, which will be used to encrypt HTTPS (secure http) and SIPS (secure SIP) traffic.

• Network Deployment installs share a common Global Security configuration and SSL configuration; this type of deployment shares the trusted root certificates by design.
• Cell installs manage their own Global Security and SSL configuration, for each server installed as a Cell deployment, as each of the servers have a common trusted root certificate.

When making SSL configurations, you should not delete the old SSL certificates. This step prevents issues that can arise when changing SSL configurations.  SSL configurations define what SSL certificate should be used; if that SSL certificate is not available, it will prevent the security and authentication modules from being loaded.  A certificate being unavailable prevents users from authenticating to the Deployment manager or other WebSphere-based authentication points.

It is important to note that completing this configuration will not force SSL traffic or redirect from HTTP to HTTPS, and the applications will still be available over HTTP.  To implement redirection from HTTP to HTTPS, refer to the article Forcing Sametime 8.5.2 WebSphere Application server to use HTTPS TLS encryption.

Method to configure and install third-party SSL certificates on Sametime 8.5.2 WebSphere Application servers

 

Adding trusted root and intermediary certificates to the Cell default trust store

 Because the System Console cell is used to manage all the servers in the infrastructure, the operations below are performed on the System Console deployment manager, so that the configuration information is available to all nodes and servers in the cell. Note that the same procedural steps can be applied to other deployment managers or into stand-alone nodes.

1. Copy the trusted and intermediate certificates to the server that will be used to install the SSL certificates into the trust store. In a cell configuration, this is the deployment manager server; in an unmanaged node configuration, this is on the unmanaged node. Put the certificates into a temporary directory such as "C:\SSLCerts".
2. Log in to the Integrated Solutions Console, using the Administrator credentials provided when the server was installed.
3. Navigate to Security –> SSL certificate and key management. Under Related Items, click the "Key stores and certificates" link.
4. Click the name of the TrustStore. Because all Sametime 8.5.2 WebSphere components are managed by an DMGR, when selecting the TrustStore we will always choose ‘CellDefaultTrustStore’.
5. Under Additional Properties, click the "Signer certificates" link. Here we add each trusted root and any intermediary certificates to the CellDefaultTruststore. When adding the trusted certificates, start with the root CA first then add any intermediary certificates thereafter. This step is completed by clicking the "Add" button.
1. In the Alias field of the next window (see figure 9), enter the alias name for the SSL entry, for example, CORP Root CA. As a best practice, the alias should be the name of the certificate.
2. In the File name field, enter the file name from entry in the table, for example, C:\SSLCerts\CORP Root CA.cer. The file specified in this field will be read on the server. If the file has not been copied to the server, copy the file to the path specified before continuing.
3. Leave the Data type field as Base64-encoded ASCII data. Click Apply and click OK.
4. Repeat this procedure until all the intermediate certificates that complete the certificate chain have been added to the CellDefaultTruststore.
6. Verify that the signer certificate has been imported (see figure 10), and save the changes to the master configuration.
7. Synchronize each node which this configuration applies to, and restart each node.  If a node is not able to synchronize with the Deployment manager, stop here and review the following article to perform a manual syncNode: syncNode command

Once each of the above steps have been completed, the WebSphere Application servers now trust the Certificate Authority who provided the third-party SSL certificates. 

Generating a certificate signer request

 1.       Log in to the Sametime System Console, and navigate to Security – SSL certificate and key management. Under Related Items, select Key stores and certificates, and in the Key stores and certificates window, select the CellDefaultKeystore.  Then under Additional Properties, select Personal certificate requests.

Note: It is recommended to request and receive all personal server certificates in the CellDefaultKeyStore. This method ensures all servers in the Cell will trust these certificates.

2.      In the "Personal Certificate" view, click 'New' to generate a new certificate request. This action displays the Personal Certificate request form.  The information you provide in this form is used to generate the certificate signer request that is sent to the Certificate Authority for signing.  See the table below for examples and descriptions of the fields that need to be populated.

Examples for populating Certificate Requests form fields:

Field	Description	Example
File Name	Provide a path to the location where the CSR will be written. Any file with the same name in the location will be overwritten	C:\SSLCSR\stmeetings.csr
Key Label	Arbitrary name in the WAS configuration that identifies the certificate	stmeetings
Key Strength	Size of the certificate’s encryption key Note: Starting in June 2010, the new SSL standard has moved to use 2048-bit encryption instead of the previous 1024	2048
Common Name	Fully qualified hostname to be SSL enabled. The fully qualified name must be resolvable in DNS	Stmeetings.acme.com
Organization	Company name	Acme
Organizational Unit	Name of the Organizational Unit requesting the certificate	Information Technology
Locality	Location where the company is registered	Albuquerque
State or Province	Name of the state or province where the company is registered. Do not use abbreviations	New Mexico
Country Code	Two-character country code	US

3.      Once the correct information has been filled in Click Apply, to save it to the master configuration. The certificate request has been created in the specified file location and in the CellDefaultKeystore which functions as a temporary place holder for the signed certificate, until you receive the certificate in the keystore.

4.      Now that the Certificate Signing Request (CSR) has been created, it is ready to send to the Certificate Authority for signing. Locate the certificate request in the file location you specified when generating the request and send this file to the Certificate Authority for signing. 

Installing a signed certificate

When a Certificate Authoring (CA) receives a CSR, it will issue a new certificate that is used to pick up the new official CA-issued certificate. The WebSphere Application Server (WAS) keystore will receive the CA-issued certificate, and the information in the certificate is used to generate a CA-signed personal certificate that the WebSphere Application server uses for SSL security.

To successfully receive the certificate from the CA, the trusted root and intermediate root certificates from the certificate must be installed in the truststore on the WebSphere Application server.

1. Copy the signed certificate to the server hosting the Sametime System Console.
2. Log into the Sametime System Console, and select Security - SSL certificate and key management Under Related items, select Key stores and certificates, and in the Key stores and certificates page, select the keystore CellDefaultKeyStore.
3. Under Additional properties select "Personal Certificates," then select "Receive for certificate authority."  This action prompts you for the signed certificate file name. Enter the full path to the signed certificate. Leave the ‘Data type’ field set to ‘Base64-encoded ASCII data.’  Click apply, then save the changes to the master configuration.
4. Validate that the new certificate is present in the Personal Certificates table. Starting in WebSphere 7, this page should also show the Certificate Authority trust chain, which will confirm that you have installed any root and intermediary certificates correctly.

Configuring the servers to use the signed certificate

Once the signed certificate has been installed in the CellDefaultKeyStore, we need to configure the server to use this certificate to encrypt data when using a secure port.

1.       Log in to the Sametime System Console, select Security -> SSL certificate and key management, then select "Manage endpoint security configurations."  This action displays a Local Topology tree of your environment; note that there are ‘Inbound’ and ‘Outbound’ sections.

2.       Expand the Inbound section and expand the node(s) that will be using the signed certificate you installed in the previous step.  Note: For cluster configurations, multiple nodes may share a common SSL certificate, only if there is a WAS proxy or Load balancer that is listing on the hostname specified in the SSL certificate.

3.       Under the expanded node that will be using the SSL certificate, select the WebSphere Application server hosting the application.  Following our example above using the Sametime Meeting server, we would select (click on the link, don't expand) "STMeetingserver."  If  a WebSphere proxy exists on the same node, then repeat Steps 3-4 on the WebSphere proxy Application, for example "WP_STMeetings."

4.       This action brings us to the general properties page for this node; locate the section identified as "Specific SSL configuration for this endpoint."

5.       Repeat above steps 2 through 4 on the ‘Outbound’ section of the Local Topology tree.  Once the certificate is applied to the WebSphere Application server correctly, the keystore and certificate alias will be reflected in the endpoint security configuration tree.

6.       Validate that all WebSphere application servers and WebSphere proxy server providing service to applications are using the correct certificates for both ‘Inbound’ and ‘Outbound’ configurations.  Restart all WebSphere servers and nodes affected by the configuration change. Once up and running, in the SSC navigate to System Administration -> nodes, and confirm all affected nodes have a green circle to the right of the node name. This green circle tells us the nodes are properly synchronized.

7.       The Final step is to confirm that the server is using the SSL configuration. Access the application via a web browser, using the fully qualified name that is on the certificate. The certificate security alert should not display now, and depending on your browser you should be able to view the SSL certificate in use. In the above example, the Sametime Meetings service is accessed through URL, https://stmeetings.acme.com/stmeetings

You will need to complete each of the following sections for each additional Sametime 8.5.2 WebSphere Application server that has a unique hostname.  In the example we outlined the process to secure the WebSphere based Sametime 8.5.2 Meeting Server.  To secure the WebSphere based Sametime 8.5.2 Proxy web client server, you would repeat the following sections outlined above:

i. Generating a certificate signer request

ii. Installing a signed certificate
iii. Configuring the servers to use the signed certificate

Additional information

For screen captures and further elaboration on SSL/TLS configuration on the Sametime WebSphere Application servers, refer to this article: Enabling SSL in IBM Lotus Sametime 8.5.1: A complete guide 

In some situations, it is preferred or required to have a Certificate created with Subject Alternative Names. If so, refer to the following link to learn about Subject Alternative Name Certificates:

http://www.openssl.org/docs/apps/x509v3_config.html#Subject_Alternative_Name_

 If a Subject Alternate Name Certificate is to be used, the process mirrors the steps above with the exception of the Certificate request.