CLM 설치 - IHS/Plugin/WAS를 이용한 Reverse Proxy

This part of the guide will explain how to setup and configure an example CLM environment using WebSphere Application Server (WAS), IBM HTTP Server (IHS) and the WAS web server plugins for IHS, such that users will be able to access the various CLM applications simply by changing the context root of a central URL which is processed by IHS. IHS will take care of sending the requests to the appropriate JTS/CCM/QM/RM application servers living behind the proxy.

Configuring the WebSphere and HTTP Server plugin method

There are two methods used to deploy the WAS Web Server plugins depending on whether IHS and the WAS profiles are local or remote. To demonstrate both methods, we will assume that the JTS, RM and CCM application server profiles are co-located with the IHS server (local), with the QM application on it's own server (remote).

The user accessible Public URIs (and the actual servers they redirect to) will be:
https://clm.example.org/qm (https://qmserver01.example.org:9443/qm)
https://clm.example.org/jts   (https://clm.example.org:9447/jts)
https://clm.example.org/rm   (https://clm.example.org:9448/rm)
https://clm.example.org/ccm   (https://clm.example.org:9449/ccm)

We will also configure single sign-on with WAS such that a user only needs to log into one of the products and subsequent access to the other applications will not require re-authentication. The configuration will use an LDAP directory.
Experienced WAS administrators will be aware that the WAS configuration steps in this guide can be carried out in different ways using "wsadmin" or the WAS Integrated Solutions console.

N.B.Note that all of the setup and configuration documented here MUST be done *before* running the JTS setup wizard to ensure that the public URIs are set correctly to the external URIs.

Example server configuration

For the purposes of this article we use two separate Windows 2008 servers configured as follows:

Server 1 (Host-name: clm.example.org):

IBM HTTP Server already installed, listening on port 80 with the IHS Administrative console on port 8008

WAS profile with JTS, Admin and CLMHelp applications deployed (HTTPS port : 9447)
WAS profile with CCM WAR deployed (HTTPS port : 9449)
WAS profile with RM WAR deployed (HTTPS port : 9448)
LDAP Server 

Server 2 (Host-name: qmserver01.example.org): 

WAS profile hosting QM (HTTPS port: 9443)

Prerequisites and Assumptions

• Use the instructions provided in the CLM Infocenter to deploy the different applications
• Each of the WAS profiles is configured to use LDAP domain "example.org" for authentication 
• IBM WebSphere plugin installation media is available
• Administrative console access to each WAS profile is available
• Username and password available for access to IHS Administrative console
• Firewalls on the two servers are configured appropriate, allowing access to the internal ports only between the Server 1 and Server 2. In other words ports 9443, 9447, 9448, 9449, 8008 are not visible to the outside world
• The firewall on Server 1 allows access to port 443 from the outside world

N.B. The Jazz platform currently does not support clustering, as a result the current tested and supported WebSphere platforms are Base only and do not included WebSphere ND. This means that for a multi-node deployment a manual merge of the plugin-cfg.xml file will be required.

---

Procedure

Create a key database and self-signed certificate for IHS

In this step we create a CMS keystore database file and a self-signed certificate which are needed to authenticate IHS during an SSL handshake. Note that Self-signed certificates should only be used for test/development scenarios. In production environments use the appropriate organizational certificates provided by a trusted certificate authority. We will later add the WAS certificates to this same keystore database.
Make sure the IHS Server is stopped
Run the "gsk7cmd" utility (alternatively use the ikeyman GUI) to create a new keystore database (ihskeys.kdb) and password stash file (ihskeys.sth) both of which will be created in the current directory (C:/IBM/HTTPServer/bin in this example).

gsk7cmd.bat -keydb -create -db ihskeys.kdb -pw secret -expire 365 -stash -type cms


  Create a self-signed certificate and add it to the the new keystore db

gsk7cmd.bat -cert -create -db ihskeys.kdb  -label clm.example.org -expire 365 -dn "CN=clm.example.org" -default_cert yes -pw secret




Enable SSL directives within the IBM HTTP Server's configuration file (httpd.conf)

In this step we need to first direct IHS to load the SSL support module (mod_ibm_ssl.so) and then direct IHS to listen for secure requests (on port 443 in this example). We also need to point IHS to the key database file (ihskeys.kdb) and password stash file (ihskeys.sth) that were created earlier.
Add (or uncomment) the following lines in httpd.conf, making sure that the values for the KeyFile and SSLStashFile directives match the names of the files generated in the previous section:

LoadModule ibm_ssl_module modules/mod_ibm_ssl.so

Listen 0.0.0.0:443
## Uncomment for IPv6 support:
#Listen [::]:443

SSLEnable
KeyFile C:/IBM/HTTPServer/bin/ihskeys.kdb
SSLStashFile C:/IBM/HTTPServer/bin/ihskeys.sth
SSLDisable    

Setup SSL Handshake Between the WAS profiles and IHS


N.B. This step can be scripted using the wsadmin AdminTask.createKeyStore and AdminTask.exportCertificate commands. See the attached CLMReverseProxy.py for an example.

Now we need to proxy SSL requests from IHS to the WAS servers by exporting the WAS keys and importing them  into the IHS keystore database previously created.

1. Login to the WAS Integration Solutions Console for the JTS profile.
2. Navigate to Security -> SSL certificate and key management -> Key Stores and Certificates, create a new Key store with the following values:
   Name: jtswaskeys
   Path: jtswaskeys.kdb
   Type: CMSKS
   Password:secret
    
3. Click OK then Save. This will create the file /etc/jtswaskeys.kdb.
4. Navigate to SSL certificate and key management -> Key stores and certificates -> NodeDefaultKeyStore
5. Choose "Personal certificates" from the right sidebar
6. Check the default certificate and click Export.
7. Specify the following values in the Export certificates pane:
   Key Store Password: WebAS (unless this has been changed)
   Select the "Key Store File" radio button
   Key File Name: jtswaskeys.kdb
   Type: CMSKS
   Password: secret
8. Click OK. This will export the default WAS personal certificates into /etc/jtswaskeys.kdb.
9. Add the certificates from the exported keystore (jtswaskeys.kdb) into the previously created IHS keystore(ihskeys.kdb). 

cd C:\IBM\HTTPServer\bin
gsk7cmd -cert -import -db /etc/jtswaskeys.kdb -pw secret -type cms -target ihskeys.kdb -target_pw secret -target_type cms -label default -new_label default_jtswas



Repeat the above steps, changing the value of Key File Name as appropriate for each of the CCM(ccmwaskeys.kdb), RM (rmwaskeys.kdb)and QM profiles (qmwaskeys.kdb). Note that since the QM WAS profile is *not* co-located with the IHS server, we first need to copy "qmwaskeys.kdb" to the IHS server.

Force WAS To Honor Host Headers


N.B. This step can be scripted using the wsadmin AdminConfig.list and AdminConfig.create commands. See the attachedCLMReverseProxy.py for an example.

To avoid a problem with Jazz redirecting to :9443 ports on the IHS Server we need to set a couple of Web Container custom properties in WAS.

1. Login to the WAS Integration Solutions Console for each WAS profile and navigate to Servers -> Server Types -> WebSphere application servers -> server1 
2. Under "Container Settings" expand Web Container Settings. Choose "Web Container".
3. Add the following custom properties:

trusthostheaderport = true
com.ibm.ws.webcontainer.extracthostheaderport = true



Single Sign-On(SSO) with WAS

To alllow sharing of authentication tokens between the different WAS profiles, we need to enable the SSO property in each WAS profile, export the LTPA (Lightweight Third Party Authentication) keys from one profile and import them into each of the other profiles.


Part I: Setup JTS profile for SSO and export keys

N.B. This step can be scripted using the wsadmin AdminTask.configureSingleSignon and AdminTask.exportLTPAKeys commands. See the attached CLMReverseProxy.py for an example.

1. Login to the WAS Integration Solutions Console for the JTS WAS profile.
2. Navigate to Global Security -> Web and SIP Security -> Single sign-on (SSO) and set the following properties:
   Enabled 
   Domain name: example.org
   Requires SSL
   
3. Click OK then Save.
4. Navigate to Global Security,select LTPA and enter the following values:
   Password : secret
   Confirm Password : secret
   Fully qualified key file name : jtsssokey
5. Click Export keys.
6. Click OK then Save. This will create a file /jtsssokey which we will import into the other WAS profiles.
7. Stop and restart the JTS profile.



Part II: Setup RM, QM and CCM for SSO and import JTS keys

N.B. This step can be scripted using the wsadmin AdminTask.configureSingleSignon and AdminTask.importLTPAKeys commands.

1. Copy the jtssokey generated above from to /jtsssokey
2. Login to the WAS Integration Solutions Console for the RM WAS profile.
3. Navigate to Global Security -> Web and SIP Security -> Single sign-on (SSO) and set the following properties:
   Enabled
   Domain name : example.org
   Requires SSL 
   
4. Click OK then Save.
5. Navigate to Global Security,select LTPA and enter the following values:
   Password : secret
   Confirm Password : secret
   Fully qualified key file name : jtsssokey
6. Click Import keys.
7. Click OK then Save.
8. Stop and restart the RM profile.
Repeat the above steps for each of the CCM and QM profiles, copying the jtsssokey file to the and respectively.

Configure WAS IHS Plug-in for JTS (Server 1)

We will now use the WAS Web Server Plugin install wizard to configure IHS such that all requests to https://clm.example.org/jts,https://clm.example.org/admin and https://clm.example.org/clmhelp are redirected to https://clm.example.org:9447/jts,https://clm.example.org:9447/admin and https://clm.example.org:9447/clmhelp respectively. As noted before, for the purposes of this example, the WAS profile to which the JTS, Admin and CLMHelp applications have been deployed is co-located on the same server as IHS. We therefore use the procedure described in Configuring a Web server and an application server profile on the same machine.

The following steps are performed on "Server 1' which hosts both IHS and the WAS profile hosting the JTS, Admin and CLMHelp applications.

1. Generate the plugin configuration file

1. Stop the JTS WAS profile.
2. Stop IHS.
3. Launch the Plug-ins installation wizard.
4. Clear the check box for the roadmaps and click Next.
5. Read the license agreement and accept the agreement it if you agree to its terms. Click Next.
6. Select "IBM HTTP Server V7" for Web server type and click Next.
7. Select WebSphere Application Server machine (local) and click Next.
8. Specify a location for the installation root directory for the plug-ins. Click Next. (Click Yes if prompted with a warning that the directory is not empty).
9. Specify the Application Server Installation Location root directory and click Next.
10. Select the profile that the JTS, Admin and CLMHelp applications are deployed to and click Next.
11. Click Browse to select the configuration file for IHS, verify that the Web server port is correct, and then click Next when you are finished.
12. Specify a unique nickname for the Web server. Click Next when you are finished.
13. Specify the location for the plugin-cfg.xml file to be generated and click Next.
14. Click Next on the pre-installation summary panel to begin the installation. The wizard begins installing the plug-ins and configuring the Web server and the application server. Not the path of the Plug-in configuration file, which we will use later.
    
15. Verify the success of the installation on the Installation summary panel and click Finish to exit the wizard.

2. Edit httpd.conf

1. Open the IHS httpd.conf file in a text editor and verify that the following two lines have been added to the end of it.

LoadModule was_ap22_module "C:\IBM\HTTPServer\Plugins\bin\32bits\mod_was_ap22_http.dll"
WebSpherePluginConfig "C:\IBM\HTTPServer\Plugins\config\webserver1\plugin-cfg.xml"

2. Open the generated plugin configuration file (C:\IBM\HTTPServer\Plugins\config\webserver1\plugin-cfg.xml in this case) and modify the keyring and stashfile properties of the HTTPS Transport attributes to use the IHS keyfile and SSL Stashfile.

 C:/IBM/HTTPServer/bin/ihskeys.kdb"/>
 C:/IBM/HTTPServer/bin/ihskeys.sth"/>     

3. Start IHS and the JTS WAS profile.
First verify that you can access the JTS page using the "internal" URL: https://clm.example.org:9447/jts. Next verify that the IHS URL https://clm.example.org/jts displays the same page.



Configure WAS IHS Plug-in for RM and CCM applications (Server 1)

We will now use the WAS Web Server Plugin install wizard to configure IHS such that all requests tohttps://clm.example.org/rm and https://clm.example.org/ccm are redirected to https://clm.example.org:9448/rm andhttps://clm.example.org:9449/ccm respectively. As noted before, for the purposes of this example, the WAS profiles to which the RM and CCM applications have been deployed are co-located on the same server as IHS. We therefore use the procedure described in Configuring a Web server and an application server profile on the same machine.
 This is similar to the procedure used for the JTS with the exception that we will need to manually merge some of the content from the plugin configuration file generated for the RM and CCM profiles into the plugin configuration file already created for the JTS.

The following steps are performed on "Server 1' which hosts both IHS and the WAS profile hosting the RM, and CCM applications.

1. Generate plugin configuration file

1. Stop the RM WAS profile.
2. Stop IHS.
3. Launch the Plug-ins installation wizard on the machine.
4. Clear the check box for the roadmaps and click Next.
5. Read the license agreement and accept the agreement it if you agree to its terms. Click Next.
6. Select "IBM HTTP Server V7" for Web server type click Next.
7. Select WebSphere Application Server machine (local) and click Next.
2. Specify the location for the installation root directory for the plug-ins. Click Next. (Click Yes if prompted with a warning that the directory is not empty).
1. Specify the Application Server Installation Location root directory and click Next.
2. Select the profile that the RM application is deployed to and click Next.
3. Click Browse to select the configuration file for IHS, and then click Next. Click OK when prompted that the HTTP Server configuration file already contains plugin entries.
4. Specify a unique nickname for the Web server. Click Next when you are finished.
5. Specify the location for the plugin-cfg.xml file and click Next.
   Note that the location for this should be different to that of the plugin configuration file previously generated for the JTS.
6. Click Next on the pre-installation summary panel to begin the installation. The wizard begins installing the plug-ins and configuring the Web server and the application server. Note the path of the Plug-in configuration file, which we will use later.
7. Verify the success of the installation on the Installation summary panel and click Finish to exit the wizard.

3. Edit httpd.conf

We pointed the wizard to the same httpd.conf file as when we configured the JTS profile and it will have modified it to use the new plugin configuration file generated for the RM profile. We need to edit it to revert it to the previous configuration where it uses the plugin configuration generated for the JTS.
Open the IHS httpd.conf file, uncomment the following two lines.


LoadModule was_ap22_module "C:\IBM\HTTPServer\Plugins\bin\32bits\mod_was_ap22_http.dll"
WebSpherePluginConfig "C:\IBM\HTTPServer\Plugins\config\webserver1\plugin-cfg.xml"

and delete the following two lines:



LoadModule was_ap22_module "C:\IBM\HTTPServer\Plugins\bin\32bits\mod_was_ap22_http.dll"
WebSpherePluginConfig "C:\IBM\HTTPServer\Plugins\config\webserver_rm\plugin-cfg.xml"

Save the httpd.conf file.


4. Merge plugin directives

We now need to follow the procedure in Merging plugin-cfg.xml files from multiple nodes and manually merge in the appropriate sections from the plugin configuration generated for the RM profile into the plugin configuration generated for the JTS.
Open the plugin configuration file generated when configuring the JTS profile (C:\IBM\HTTPServer\Plugins\config\webserver1\plugin-cfg.xml in this case) in a text editor. Also open the plugin configuration file generated when configuring the RM profile (C:\IBM\HTTPServer\Plugins\config\webserver_rm\plugin-cfg.xml in this case) in a separate text editor window.
Copy and paste the following lines

from the webserver_rm\plugin-cfg.xml to the  element in webserver1\plugin-cfg.xml, so that the element now looks like

Next copy over the , and elements from the webserver_rm\plugin-cfg.xml  to the webserver1\plugin-cfg.xml, pasting them before the closing tag.
Also modify the keyring and stashfile properties of the HTTPS Transport attributes for port 9448 to use the IHS keyfile and SSLStashfile.


 C:/IBM/HTTPServer/bin/ihskeys.kdb"/>
 C:/IBM/HTTPServer/bin/ihskeys.sth"/>


Save the webserver1\plugin-cfg.xml.
Start IHS and the RM WAS profile.
First verify that you can still access the JTS page using the IHS URL https://clm.example.org/jts.
Next verify that you can access the RM page using the "internal" URL: https://clm.example.org:9448/rm. Next verify that the IHS URL https://clm.example.org/rm displays the same page.


Repeat the above steps for the CCM profile, modifying the WAS profile used to "ccm", the webserver nickname to "webserver_ccm" and the plugin configuration file to "C:\IBM\HTTPServer\Plugins\config\webserver_ccm\plugin-cfg.xml".



Configure WAS IHS Plug-in for the QM application (Server 2)

We will now use the WAS Web Server Plugin install wizard to configure IHS such that all requests tohttps://clm.example.org/qm are redirected to https://qmserver01.example.org:9443/qm and. As noted before, for the purposes of this example, the WAS profile to which the QM application has been deployed is *not* co-located on the same server as IHS. We therefore use the procedure in Configuring a Web server and an application server on separate machines (remote). This is similar to the procedure used for the RM and CCM applications with the exception that we will use the IHS Admin console from the QM WAS profile to propagate the plugin configuration file to the IHS server.

The following steps are performed on "Server 1' which hosts IHS.

1. Generate manual plugin configuration script

1. Stop IHS.
2. Launch the Plug-ins installation wizard on the server where IHS is installed (Server 1).
3. Clear the check box for the roadmaps and click Next.
4. Read the license agreement and accept the agreement it if you agree to its terms. Click Next.
5. Select "IBM HTTP Server V7" for Web server type click Next.
6. Select Web Server  machine (remote) and click Next.
7. Specify the location for the installation root directory for the plug-ins. Click Next. (Click Yes if prompted with a warning that the directory is not empty).
8. Click Browse to select the configuration file for IHS, and then click Next. Click OK when prompted that the HTTP Server configuration file already contains plugin entries.
9. Specify a unique nickname for the Web server. Click Next when you are finished.
10. Specify the location for the plugin-cfg.xml file and click Next.
    Note that the location for this should be different to that of the plugin configuration file previously generated for the JTS.
11. Specify the host-name (qmserver01.example.org) of the server hosting the QM WAS profile.
12. Click Next on the pre-installation summary panel to begin the installation. The wizard begins installing the plug-ins and configuring the Web server and the application server. Note the path of the Plug-in configuration file, which we will use later.
13. Once the installation completes, the wizard generates a manual configuration script which must be run on the QM server. The path to the script is displayed in the installation summary panel.
14. Verify the success of the installation on the Installation summary panel and click Finish to exit the wizard.



2. Edit httpd.conf

We pointed the wizard to the same httpd.conf file as when we configured the JTS profile and it will have modified it to use the new plugin configuration file generated for the QM profile. We need to edit it to revert it to the previous configuration where it uses the plugin configuration generated for the JTS.
Open the IHS httpd.conf file, uncomment the following two lines.


LoadModule was_ap22_module "C:\IBM\HTTPServer\Plugins\bin\32bits\mod_was_ap22_http.dll"
WebSpherePluginConfig "C:\IBM\HTTPServer\Plugins\config\webserver1\plugin-cfg.xml"

and remove the following two lines:



LoadModule was_ap22_module "C:\IBM\HTTPServer\Plugins\bin\32bits\mod_was_ap22_http.dll"
WebSpherePluginConfig "C:\IBM\HTTPServer\Plugins\config\webserver_qm\plugin-cfg.xml" 

Save the httpd.conf file.



The following steps are performed on "Server 2' which hosts the WAS profile hosting the QM application.

3. Run manual configuration script on Server 2

We now copy the manual configuration script generated above (C:\ibm\HTTPServer\Plugins\bin\configurewebserver_qm.bat) to the /bin directory on Server 2.
If the WAS profile hosting the QM application isn't already running start it.
Run the  configurewebserver_qm.bat script:


C:\ibm\WebSphere\AppServer\bin>configurewebserver_qm.bat  -profileName qm -user wasadminuser -password wasadminpassword
Using the profile qm
Using WebSphere admin userID wasadminuser
WASX7209I: Connected to process "server1" on node qm using SOAP connector;  
The type of process is: UnManagedProcess
WASX7303I: The following options are passed to the scripting environment and are
available as arguments that are stored in the argv variable: "[webserverqm, IHS, C:\\IBM\\HTTPServer, C:\\IBM\\HTTPServer\\conf\\httpd.conf, 
80, MAP_ALL, C:\\IBM\\WebSphere\\Plugins, unmanaged, clm.example.org-node, clm.example.org, windows]"
Input parameters:
 Web server name             - webserverqm
 Web server type             - IHS
 Web server install location - C:\IBM\HTTPServer
 Web server config location  - C:\IBM\HTTPServer\conf\httpd.conf
 Web server port             - 80
 Map Applications            - MAP_ALL
 Plugin install location     - C:\IBM\WebSphere\Plugins
 Web server node type        - unmanaged
 Web server node name        - clm.example.org-node
 Web server host name        - clm.example.org
 Web server operating system - windows
 IHS Admin port              - 8008
 IHS Admin user ID           - ""
 IHS Admin password          - ""
 IHS service name            - ""
....

Start saving the configuration.

Configuration save is complete.




4. Propagate the QM plugin configuration file to the IHS server

Login to the WAS Integration Solutions Console for the QM WAS profile.
Navigate to Servers -> Server Types -> Web Servers
Click "webserver_qm" and click "Remote web server management"

Specify the Port, Username and password to allow WAS to connect to the IHS Admin console. Click OK and Save.


 Select "webserver_qm" and click "Generate Plug-in".


Once the plugin file has been generated, select  select "webserver_qm" and click "Propagate Plug-in".


If successful WAS will generate a message such as:


InformationPLGC0062I: The plug-in configuration file is propagated from 
C:\ibm\WebSphere\AppServer\profiles\qm\config\cells\qm\nodes\clm.example.org-node\servers\webserver_qm\plugin-cfg.xml 
to C:\IBM\HTTPServer\Plugins/config/webserver_qm/plugin-cfg.xml on the Web server computer.
InformationPLGC0048I: The propagation of the plug-in configuration file is complete for the Web server. 
qm.clm.example.org-node.webserver_qm.                                 

Note the path displayed for the generated plugin configuration file on Server 1 which is the IHS Server:


C:\IBM\HTTPServer\Plugins/config/webserver_qm/plugin-cfg.xml



The following steps are performed on "Server 1' which hosts IHS.

5. Merge plugin directives

We now need to follow the procedure in Merging plugin-cfg.xml files from multiple nodes and manually merge in the appropriate sections from the plugin configuration generated for the QM profile into the plugin configuration generated for the JTS.
Open the plugin configuration file generated when configuring the JTS profile (C:\IBM\HTTPServer\Plugins\config\webserver1\plugin-cfg.xmlin this case) in a text editor. Also open the plugin configuration file generated when configuring the QM profile (C:\IBM\HTTPServer\Plugins\config\webserver_qm\plugin-cfg.xml in this case) in a separate text editor window.
Copy and paste the following lines

from the webserver_qm\plugin-cfg.xml  to the  element in webserver1\plugin-cfg.xml, so that the element now looks like

Next copy over the , and elements from the webserver_qm\plugin-cfg.xml  to the  webserver1\plugin-cfg.xml, pasting them before the closing tag.
Also modify the keyring and stashfile properties of the HTTPS Transport attributes for port 9448 to use the IHS keyfile and SSLStashfile.

 C:/IBM/HTTPServer/bin/ihskeys.kdb"/>
 C:/IBM/HTTPServer/bin/ihskeys.sth"/>         

Save the webserver1\plugin-cfg.xml.
Start IHS.
First verify that you can still access the JTS page using the IHS URL https://clm.example.org/jts.
Also verify that you can still access the RM and CCM pages using the IHS URLs https://clm.example.org/rm andhttps://clm.example.org/ccm respectively.
Next verify that you can access the QM page using the "internal" URL: https://qmserver01.example.org:9443/qm. and then  verify that the IHS URL https://clm.example.org/qm displays the same page.

Running the JTS Setup wizard

Now that we have URLs that are server agnostic we can run the JTS setup wizard and use these URLs when registering the applications. Here are the discovery URLs that will be used:

Requirements Management: https://clm.example.org/rm/scr
Quality Management: https://clm.example.org/qm/scr
Change and Configuration Management: https://clm.example.org/ccm/scr
Lifecycle Project Administration: https://clm.example.org/admin/scr

Moving an application

Now suppose that we wish to redeploy the CCM application to it's own separate server (for example, ccmserver01.example.org) without affecting users' ability to access it through https://clm.example.org/ccm. Here is a summary of the steps, previously detailed, to be repeated:

1. Deploy the CCM application to WAS on ccmserver01.example.org
   Follow the instructions in the CLM Infocenter, making sure to copy over the directory that contains the indexes and configuration files, located at /server/conf/ccm for the CCM application from the original server.
2. Setup SSL Handshake Between WAS profile on ccmserver01.example.org and IHS on clm.example.org
   Follow the procedure detailed in Setup SSL Handshake Between the WAS profiles and IHS, creating a new "ccmwaskeys.kdb" keystore from the new WAS profile, copying this keystore over to the IHS server and using gs7cmd to import it into the IHS keystore (ihskeys.kdb).
3. Force WAS To Honor Host Headers
   Follow the procedure in Force WAS To Honor Host Headers on the new WAS profile hosting the CCM application.
4. Setup Single Sign-On(SSO) with WAS and import JTS keys
   Follow the procedure in Part II: Setup RM, QM and CCM for SSO and import JTS keys to set the domain name and  import the keys from thejtsssokey key file.
5. Configure WAS IHS Plug-in for the CCM application
   Follow the procedure in Configure WAS IHS Plug-in for the QM application (Server 2) to generate the plugin configuration script for the CCM profile, edit the httpd.conf file, copy the generated script to the new CCM server, run the script and propagate the plugin configuration back to the IHS server
6. Replace plugin directives
   Finally follow the procedure in Merge plugin directives this time replacing the CCM application related entries in the merged plugin configuration file (C:\IBM\HTTPServer\Plugins\config\webserver1\plugin-cfg.xml) with the  corresponding entries from the plugin configuration generated for the  new CCM WAS profile.