To set up NexJ Customer Relationship Management on WebSphere Application Server (WAS), you need to install and configure WAS and then deploy NexJ CRM on the WAS environment.

The instructions in this section refer to the following locations and variables:

NEXJ_PLUGIN
The location where the NexJ Studio plugin is installed. For example, c:\nexj_studio\11.0\plugins\com.nexjsystems.nexjstudio_version.

WAS_ROOT
The location where WebSphere Application Server is installed. For example, C:\IBM\WebSphere\AppServer.

JAVA_HOME
The location where the Java JDK is installed.

profile
A set of directories and configuration files defining a run-time environment for WebSphere Application Servers.

adminHost
The name of the host machine for the WebSphere Application Server. For example, washost.nexjsystems.local.

adminPort
The port number for accessing the WebSphere Application Server on the host machine.

adminUser
The WebSphere Application Server administrator user ID.

adminPassword
The WebSphere Application Server administrator password.

To deploy NexJ CRM in the WAS environment:

1. Install the WAS server. See Installing WebSphere Application Server.
2. Create the deployment manager and node agents for your deployment.

3. [Optional] Create servers and server clusters in the WebSphere environment.

   Info

   With clustered deployment, you must set up a dedicated message queue (MQ) cluster for running the JMS engine. The MQ cluster name must be the application cluster name followed by -mq.

4. Configure the WAS installation so that it can run your NexJ application. See Configuring WebSphere Application Server.
5. [Optional] If you want to have encrypted passwords, set up password encryption. See Setting up password encryption on WebSphere Application Server.
6. Update the WAS configuration in the initialization script. See Updating the WebSphere Application Server environment configuration.
7. Using NexJ Studio, configure the environment file for your deployment with updated WAS information. See Updating the environment information for WebSphere Application Server.
8. Start the WebSphere Application Server. See Starting the WebSphere Application Server.

For more information about setting up WAS, see the WebSphere Application Server product documentation page on the IBM website.

Related links

Configuring the cluster discovery protocol

Configuring TCP on application servers

You need to set Linux kernel parameters or Windows registry keys to correctly configure TCP on the application server.

This allows the application server to recover more efficiently when TCP connections are dropped by the server.

To configure TCP on an application server:

1. Change the kernel parameter values or registry keys, based on operating-system-specific files provided with the NexJ Studio plugin.
   • On Linux, do one of the following:
     • If the /etc/sysctl.conf file exists, edit the file to match the values in the <NEXJ_PLUGIN>/core/etc/config/os/tcp-linux.conf file.
     • Otherwise, copy the <NEXJ_PLUGIN>/core/etc/config/os/tcp-linux.conf file to the /etc/sysctl.d directory. Ensure that none of the other .conf files in that directory specify the parameters listed in the tcp-linux.conf file.
   • On Windows, double-click the <NEXJ_PLUGIN>\core\etc\config\os\tcp-os.reg file, where os is one of: xp, server2003, or server2008-Vista-7. Accept the confirmation messages to update registry settings.
2. Restart the computer.

The TCP stack standard-compliance on the application server is now correctly configured.

You can now continue deploying the application server.

Installing WebSphere Application Server

Install WebSphere Application Server (WAS) on the server host machine and on the NexJ Studio host machine. After installing, ensure that the latest fix packs are applied.

To install and configure WAS:

1. Install WebSphere Application Server on the Application Server host and on the NexJ Studio host.
   During installation, enable administrative security and specify an administrative user name and password.
2. Install the binary plug-in for a supported web server, provided with the WebSphere Application Server.
3. Obtain and apply the fix packs specified in the Release Notes document for your version of the product, for the application server as well as the JVM.
   See the recommended fixes for WebSphere Application Server on the IBM web site.

Related links

www.ibm.com/support

Configuring WebSphere Application Server

After you have installed WebSphere Application Server (WAS), you need to configure it to contain NexJ-specific files and settings.

Before configuring WAS with NexJ-specific files and settings, create the application servers or application and message queue server clusters.

To configure WebSphere Application Server:

1. Copy the following files from the <NEXJ_PLUGIN> directory to the <WAS_ROOT> directory.

   File to copy	Copy to directory
   <NEXJ_PLUGIN>\nexj-websphere.jar	<WAS_ROOT>\lib\ext
   <NEXJ_PLUGIN>\nexj-boot.jar	<WAS_ROOT>\nexj\lib
   Appropriate JDBC driver, such as jtds-1.2.2-7.jar or ojdbc6.jar	<WAS_ROOT>\nexj\lib If you are using the NexJ default relational database as the user registry, also copy the JDBC driver to <WAS_ROOT>\lib\ext.

   If you are configuring nexj-websphere.jar in WebSphere as a shared library instead of copying it to the WAS_ROOT\lib\ext folder, you should configure WebSphere as follows:

   1. In WebSphere, configure the shared library settings by expanding Environment and selecting Shared Libraries.

   2. Associate the shared library with the server by expanding Servers and selecting Application Servers. Select Server Infrastructure → Java and Process Management → Class loader. If a class loader does not exist, create one and under Additional Properties click on Shared library references.

   3. Configure the Resource Adapter settings by selecting Applications → All applications → NexJ Dynamic Resource Adapter → Additional Properties → Resource Adapter. Configure the jar files in Shared Libraries under Class path.

   4. Clean all of the transaction logs for the server used to run your application.

   5. Start the server.

2. Copy the following files from the <NEXJ_PLUGIN> directory to the <JAVA_HOME> directory.

   File to copy	Copy to directory
   <NEXJ_PLUGIN>\lib\platform\*.dll	<WAS_ROOT>\java\jre\bin

3. For each WAS profile on which NexJ CRM is deployed (including the deployment manager for clustered
   environments), edit the WAS_ROOT\profiles\profile\properties\server.policy file to add the
   following:

   // NexJ classes 
   grant codeBase "file:${was.install.root}/nexj/lib/-" { 
       permission java.security.AllPermission; 
   }; 
   grant codeBase "file:${was.install.root}/lib/ext/nexj-websphere.jar" { 
       permission java.security.AllPermission; 
   };

4. Start the deployment manager or the server.
   • For a clustered configuration, start the deployment manager.
   • For a stand-alone configuration, start WAS.
5. [Optional] Set up password encryption on WAS.

6. Update the WAS environment configuration.
   [Optional] If outbound SSL SMTP or HTTP sessions are used (for example, for Exchange synchronization), and if the servers do not use authoritative certificates, import the SSL server certificates as DER encoded binary X.509 into the <WAS_ROOT>\java\jre\lib\security\cacerts directory.

   Note

   This configuration is not recommended for production deployments.

   Issue the following command:

   <WAS_ROOT>\java\jre\bin\keytool -import -trustcacerts 
             -alias <server> -file certificate.cer -keystore 
             <WAS_ROOT>\java\jre\lib\security\cacerts -storepass 
             changeit

   The <server> parameter must be unique in the keystore and it should be the name of the server which is authenticated by the certificate.

   Tip

   To debug certificate handling, use the WAS administrative console to change the value of the javax.net.debug Java virtual machine (JVM) custom property for the server to true. To access the JVM custom properties page, navigate to Java and process management → Process definition → Java virtual machine → Custom properties.

After these steps have been completed, your WebSphere Application Server installation has been configured.

You will now need to update the environment for your deployment with information about your WAS servers and connections.

Related links

Setting up password encryption on WebSphere Application Server
Updating the WebSphere Application Server environment configuration
Updating the environment information for WebSphere Application Server

Adding a custom map property for a custom TAI for SPNEGO

If you are using a custom trust association interceptor (TAI), you must add a new custom map property in WebSphere.

If you are using a custom user domain group instead of nexjusers, ensure that you have provided your group name as the authGroup security property value in your environment file. For more information, see Creating a user domain group for NexJ applications.

To add a custom map property for a custom TAI:

1. Log in to WebSphere Integrated Solutions Console.
2. Navigate to Security → Global security.
3. Expand the Web and SIP security section and click Trust association.
4. In the Additional Properties section, click the Interceptors link.
5. Click the nexj.core.container.platform.websphere.WebSphereAuthenticationTAI link.

6. Add a new custom property that is named map and has a value that uses the following format:
   <LDAPGroup>-><LDAPGroup Full DN>
   For example, the map property is equivalent to:
   
   

   Example Server Administrators->CN=Example Server Administrators,OU=_Tech Roles,
   OU=Role Groups,OU=Security,OU=AU,DC=test,DC=abc,DC=com

7. Click OK.

8. Click Save to save the changes to the configuration.

9. Restart the WebSphere Application Server deployment manager for the changes to take effect.

You have configured your custom TAI.

Setting up password encryption on WebSphere Application Server

If required, you can set up password encryption on WebSphere Application Server (WAS). Use the Cipher Tool in NexJ Studio to generate the password file, copy it to the WAS machine, and then enable encryption on the server.

Before you can set up password encryption, use the NexJ Studio Cipher Tool to generate the master password file master.pwd. If you do not have access to NexJ Studio, someone else might need to generate the file for you.

If you are not doing this task on the NexJ Studio host machine, you need to ensure that the init.jacl file has been copied from the <NEXJ_PLUGIN>\enterprise\etc\config\websphere\ directory to a directory on the WAS host machine.

Before you can set up password encryption on WAS, ensure that WAS is running.

1. Get the master password password file master.pwd, which was generated using the NexJ Studio Cipher Tool.
2. Copy this file to the WebSphere Application Server machine in the <WAS_ROOT>\nexj directory.
3. Set file permissions to make the master.pwd file readable only to the server process user (that is, the login account specified in the application server service) and the deployment administrator.

4. On the WAS host machine or the NexJ Studio host machine, start the wsadmin tool.
   Issue the following command:

   <WAS_ROOT>\bin\wsadmin -host 
               <adminHost> -port <adminPort> -username <adminUser> -password 
               <adminPassword>

5. Update the initialization script to enable encryption.

   Tip

   For explanation of the parameters, review the initialization script.

   Issue the following commands:

   source <path>\init.jacl 
   enableEncryption true 
   saveConfig 
   exit

   In this command, <path> is the absolute path to the init.jacl file.

Password encryption is now enabled for your WebSphere Application Server.

Restart WAS for the changes to take effect.

Related links

Encrypting deployment files and passwords

Updating the WebSphere Application Server environment configuration

Use the WebSphere Application Server wsadmin tool to update the WebSphere Application Server (WAS) environment configuration.

If you are not doing this task on the NexJ Studio host machine, you need to ensure that the init.jacl file has been copied from the <NEXJ_PLUGIN>\enterprise\etc\config\websphere\ directory to a directory on the WAS host machine.

Before you begin updating the environment configuration do one of the following:

• For a clustered configuration, start the deployment manager.
• For a stand-alone configuration, start WAS.

Review the init.jacl file to understand the different commands and options.

The following instructions refer to two variables:

target

Use {node server} for single-server deployment and {cluster} for clustered deployment.

target-mq

Use {node server} for single-server deployment and {cluster-mq} for clustered deployment.

To update WAS environment configuration:

1. On the WAS host machine or the NexJ Studio host machine, start the wsadmin tool.
   Issue the following command:

   <WAS_ROOT>\bin\wsadmin -host <adminHost> -port <adminPort> 
     -username <adminUser> -password <adminPassword>

2. Source the Jacl script.
   Issue the following command:
   source <path>\init.jacl
   where <path> is the absolute path to the init.jacl file.

   Tip

   Every time you start the wsadmin tool, you must issue the following command: source <path>\init.jacl.

3. Set up the service integration bus (SIBus) needed for JMS message queueing.
   Choose whether you want to have file store or database store as the message engine's store type.
   • To set up a file-based SIBus, issue the following command:
     createFileBus nexj {<dataDir>} {<target-mq>}
     For example:
     createFileBus nexj {C:\IBM\WebSphere\AppServer\nexj} {nexj-mq}

   • To set up a database-based SIBus, issue the following command:

     createSQLBus nexj <dbtype> <dbclasspath> <dbhost> <dbname> <dbauthalias> <dbuser> 
      <dbpassword> <dbowner> <location> [<jndiname>] [{<customProperties>}] [<createTables>]

     For example:
     createSQLBus nexj mssql "" localhost crm nexj "" "" "" {nexj-mq}

4. [Optional] Set up the default relational database as the user registry.
   Issue the following command:

   setupSQLUserRegistry <adminUser> <serverProcessUser> <serverProcessPassword> 
    <dbtype> <dbhost>:<dbport> <dbname> <dbuser> <dbpassword>

   
   In this command, the possible <dbtype> values are mssql, oracle, or db2 and the <serverProcessUser> is the WAS administrative user that was created during installation.

   Note

   If any of the default relational database information, such as its location or login details, change, you will need to re-run this command to ensure that the user registry and the default relational database details remain synchronized.

5. If the WAS administrator account does not match the one created when installing WAS, issue the following command:
   setupAdmin <adminUser> all
6. Specify the web server information.
   • If your WebSphere environment includes a web server or multiple web servers, issue the following command:
     setupWeb {{<node1> <webserver1>} ... {<nodeN> <webserverN>}} <cookieName> {<target>}
   • If no web servers are configured and the default cookie name is used, issue the following command:
     setupWeb {} "" {<target>}
7. Specify the JVM heap size for the servers and server clusters.
   • If your WebSphere environment consists of a standalone server, then issue the following command: setupJVM heapMB {target}.

   • Otherwise, issue the following command:

     setupJVM <heapMB> {<target>} 
     setupJVM <heapMB> {<target-mq>}

     Tip

     Specify a heap size which is big enough to provide sufficient memory to the application, but small enough to prevent process page swapping by the operating system.

     Some suggested values for a single, non-standalone node with 4 GB RAM are:

     • Application JVM: 2048 MB

     • MQ JVM: 256 MB

     • Node agent: 256 MB

     • Deployment manager: 256 MB
       For a standalone node, set the application JVM to no more than 3072 MB for a 4 GB RAM.

8. Perform a one-time configuration of the PKI infrastructure for SSL.
   Issue the following command:
   setupPKI {<target>}.

9. [Optional] If you did not enable password encryption, enable password decryption instead.
   Enabling password decryption allows WAS to recognize passwords specified in environment and server files, when the passwords are specified using the text:, base64:, or master: prefixes. Issue the following command:
   enableEncryption false.

   If you set up password encryption by following the instructions in Setting up password encryption on WebSphere Application Server, then WAS will encrypt passwords using NexJ's Master Password Encryption scheme, in addition to recognizing encrypted passwords.

10. Enable WebSphere Application Server security.
    Issue the following command:
    enableSecurity true
    Save the changes to the initialization script and exit the wsadmin tool.
    Issue the following commands:

    saveConfig 
    exit

    After these steps have been completed, the WAS environment has been configured.

Restart WAS for the changes to take effect.

Updating the environment information for WebSphere Application Server

Using NexJ Studio, update the information about WebSphere Application Server (WAS) servers and connections for your deployment.

Before you can update the environment information for WAS, ensure that there is a server or environment file for your deployment. To create a new environment file using NexJ Studio, see Creating environment files.

Ensure that you have the following information about your WAS installation, which is specified during the WAS installation and configuration process:

• adminUser
• adminPassword
• The file name of the JDBC driver, which is located in the <WAS_ROOT>\nexj\lib directory.

To configure WAS servers and connections in NexJ Studio:

1. On the Deployment layer, in the Environment tab, open the environment file or the connection and server files for this deployment.
2. In the environment or server file, on the Overview tab, ensure that Type is set to WebSphere.
3. In the Deployment Location field, specify the locations for your deployment.
   • If you are deploying a server cluster, specify the location in the following format:
     protocol://host:port/cell/cluster.
     For example:
     soap://washost.nexjsystems.local/nexjCell/nexj
   • If you are deploying a standalone server, specify the location in the following format:
     protocol://host:port/cell/node/server.
     For example:
     soap://washost.nexjsystems.local/nexjCell/Node1/server1
     If you have deployed a plugin for a webserver, append the name of the webserver to the location. For example: soap://washost.nexjsystems.local/nexjCell/nexj;webserver1.
     For multiple webservers, the format is: protocol://host:port/cell/cluster;webserver1[&webserver2...&webserverN].
     In the format examples above, <profile>, <cell>, <node>, <server>, and <webserver> values are directory names. They are based on the following directory paths:
     • <WAS_ROOT>\profiles\<profile>\config\cells\<cell>\clusters\cluster
     • <WAS_ROOT>\profiles\<profile>\config\cells\<cell>\nodes\<node>\servers\<server>
     • <WAS_ROOT>\profiles\<profile>\config\cells\<cell>\nodes\<node>\servers\<webserver>
       The <port> is optional. The default protocol is SOAP; the default adminPort value for SOAP is 8880 (8879 with a cluster). For Java Remote Method Invocation, the default adminPort value is 2809 (9809 with a cluster).
       In an environment where there are separate servers for the deployment manager and the node agents, the <host> is the deployment manager server.
4. In the Deployment User field, specify a user name.
   This can be the WAS administrative user defined when WAS was installed or another user included in the user registry, as long as that user has the deployer and configurator administrative roles defined.
5. In the Password field, specify a password.
   This can be the WAS administrative password defined when WAS was installed or a password for another user included in the user registry.
6. In the Overview tab, click the Clustering/Session subtab.
   • If you are deploying a server cluster, select the Distributed (Enable Clustering) option.
   • If you are deploying a standalone server, clear the Distributed (Enable Clustering) option.
7. In the environment or connections file, select the Data Source Connections tab.
8. For each data source connection, specify the name of your JDBC driver in the Path field. For example, jtds-1.2.2-7.jar.
9. Save the updated environment file or server and connections files.
10. Deploy the updated model.

After these steps are completed, your NexJ application has been deployed on WAS with correct environment information.

Related links

Configuring the cluster discovery protocol

Starting the WebSphere Application Server

In a clustered environment, you must start all the components of WebSphere Application Server (WAS) in a specific order.

In a standalone environment, start WAS with a single command. For example, in the command prompt, issue the following command:
<WAS_ROOT>\bin\startServer server1

To start WAS in a clustered environment:

1. Start the deployment manager. For example, in the command prompt, from the <WAS_ROOT>\bin\ directory, issue the startManager command.
2. Start the node agents.
   For example, in the command prompt, from the <WAS_ROOT>\profiles\<profile>\bin\ directory, issue the startNode command. You can also issue the following command:
   <WAS_ROOT>\bin\startNode -profileName <profile>
3. Start the Message Queue servers.
   For example, in the command prompt, from the <WAS_ROOT>\profiles\<profile>\bin\ directory, issue the startServer command. You can also issue the following command:
   <WAS_ROOT>\bin\startServer <serverName> -profileName <profile>
4. Start the application servers or server clusters.
   For example, in the command prompt, from the <WAS_ROOT>\profiles\<profile>\bin\ directory, issue the startServer command. You can also issue the following command:
   <WAS_ROOT>\bin\startServer <serverName> -profileName <profile>
   You can start several servers simultaneously by using the WebSphere Application Server Administrative Console. In the administrative console, click Servers → Clusters → WebSphere application server clusters. Select the servers or clusters whose members you want started and click Start.

After the steps have been completed, WAS is now running. If needed, you can deploy your application.

Stopping the WebSphere Application Server

In a clustered environment, you must stop all the components of WebSphere Application Server (WAS) in a specific order.

In a standalone environment, stop WAS with a single command. For example, in the command prompt, issue the following command:
WAS_ROOT\bin\stopServer server1

To stop WAS in a clustered environment:

1. Stop application servers or server clusters.
   For example, in the command prompt, from the <WAS_ROOT>\profiles\profile\bin\directory, issue the stopServer <serverName> command.
   You can stop several servers simultaneously by using the WebSphere Application Server Administrative Console. In the administrative console, click Servers → Clusters → WebSphere application server clusters.
   Select the servers or clusters whose members you want started and click Stop.
2. Stop MQ servers or server clusters.
   For example, in the command prompt, from the <WAS_ROOT>\profiles\<profile>\bin\directory, issue the stopServer serverName command.
3. Stop the node agents.
   For example, in the command prompt, from the <WAS_ROOT>\profiles\<profile>\bin\directory, issue the stopNode command. You can also issue the following command:
   <WAS_ROOT>\bin\stopNode -profileName <profile>
4. Stop the deployment manager.
   For example, in the command prompt, from the <WAS_ROOT>\bin\ directory, issue the stopManager command.

After these steps have been completed, WAS is no longer running.

<WAS_ROOT>\bin\stopServer <server> -username <adminUser> 
          -password <adminPassword>

Troubleshooting WebSphere Application Server problems

If you receive the following errors when configuring WebSphere Application Server (WAS), review the suggested solutions.

syncNode.sh <DMgr_hostName> <DMgr_SOAPPort> - username <adminUser> -password <adminPassword>

<WAS_ROOT>\profiles\<profile>\bin\retrieveSigners ClientDefaultKeyStore ClientDefaultTrustStore -host <adminHost> -port <adminPort> - username <adminUser> -password <adminPassword>

To help with troubleshooting, review the system log files located in the <WAS_HOME>/profiles/<profile>/logs directory.

Configuring two-way SSL authentication for inbound traffic

You can configure two-way SSL authentication for inbound traffic to the WebSphere Application Server (WAS).

When two-way SSL authentication is configured, external systems can initiate calls to WAS. Then, WAS completes the SSL handshake and authentication. If a web server is deployed, traffic passes anonymously to the WAS server, which then completes the SSL handshake and authentication.

To enable two-way SSL authentication, you must:

• Import the public certificate of the external system to the WAS trust store.
• Import the client certificate for WAS into the WAS keystore. This client certificate may already exist or it must be provisioned by a Certificate Authority.
• Generate and add a Base-64 encoded copy of the public certificate to the HTTPConnection parameter in the environment file.
• Create a new user in the WebSphere user account repository (in Active Directory (AD), Lightweight Directory Access Protocol (LDAP), or the internal file repository) using the user name from the public certificate for the external system.

Before configuring two-way SSL for the application server, ensure that you have the following certificates.

You must also generate a Base-64 encoded copy of the client.cer certificate.

To configure two-way SSL for WAS:

1. On the WebSphere Application Server host machine, back up all WebSphere profiles.
2. Restart all WebSphere processes.
3. In WebSphere, import the following certificates:
   1. Import the client.cer certificate into the CellDefaultTrustStore.
   2. Import the server.pfx certificate into the CellDefaultKeyStore.

4. In NexJ Studio, in the environment file, copy the Base-64 encoded client.cer certificate into the Trust field for the inbound HTTPConnection channel. When you copy the certificate, ensure that you preserve newline characters for the certificate, as shown in the following example:

   -----BEGIN CERTIFICATE-----
   MIIFGTCCBAGgAwIBAgIQDglpv5N//FO17+tKwyGMtDANBgkqhkiG9w0BAQsFADBN
   MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E
   aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTQwODA2MDAwMDAwWhcN
   MTYwOTA3MTIwMDAwWjBvMQswCQYDVQQGEwJDQTEQMA4GA1UECBMHT250YXJpbzEQ
   MA4GA1UEBxMHVG9yb250bzEaMBgGA1UEChMRTmV4SiBTeXN0ZW1zIEluYy4xCzAJ
   BgNVBAsTAklUMRMwEQYDVQQDDAoqLm5leGouY29tMIIBIjANBgkqhkiG9w0BAQEF
   AAOCAQ8AMIIBCgKCAQEAt2hNQUcIuZLCAbnNCnHE6NWkzo4+Jr+fswvoaCY8lQvu
   eA9jKdcLQxLRtfK6q4i/pmSEFiYnxODsrxf7ACiqia8s/itBlDa0xwWOrGPzygFa
   odSSVXgS8rGo2VjKWhjSXQYC8EkVUs1mLsKAcG8n3K3Fp0xAf7YOF5BPJQUq9XSG
   tGySchZDlTPPYbhWtRj3lDpDMOAoS7S9qB55RxjOL1GSsLiGKP+YUG6wjWB4CQwl
   8ZSoqFsq0NKG0HPMFtoe6N4G4myFtX8MoKDYLKxGtr7eFeurv0S1UlyBm5gMPbS4
   bCSXRl8K2X6ntwaBRaQl1wt34VKtoRoXiO+EmXtJMQIDAQABo4IB0TCCAc0wHwYD
   VR0jBBgwFoAUD4BhHIIxYdUvKOeNRji0LOHG2eIwHQYDVR0OBBYEFCeln20KJoCz
   psdW0UcEzp4X9LyOMB8GA1UdEQQYMBaCCioubmV4ai5jb22CCG5leGouY29tMA4G
   A1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwawYD
   VR0fBGQwYjAvoC2gK4YpaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NzY2Etc2hh
   Mi1nMy5jcmwwL6AtoCuGKWh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9zc2NhLXNo
   YTItZzMuY3JsMEIGA1UdIAQ7MDkwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEW
   HGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwfAYIKwYBBQUHAQEEcDBuMCQG
   CCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRgYIKwYBBQUHMAKG
   Omh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJTZWN1cmVT
   ZXJ2ZXJDQS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAG395
   LDTPwvm88mTy+QfO1AEMChO9cj82rsBmsBldblPnSY1PGsmwml29DFYrz1BISufp
   kqx3zLdcfBsp78B5pmfyDbjZtHiUbDuNZfMGK0MoOiqt4chBwbo3sf9SerbKfYig
   FfGr2dtlddm2i9RU98G0NDNwthofDB3hWn23A5ENfXRj/CJj0cJTxzrTVxboVAOa
   dCUs8D/o0Xsl8vovQtSunVF00P3QFiondp50ICiKFUMgsEYyJwLnHO9wLmN+B29o
   kxlTKdBvobvCJz5Q5AMsh9ohqw/X3wTHd9o9ozCeMTyVVwrsv2XkVcsIKSkOmLq1
   cNoZIv6P+fLm0RWBvA==
   -----END CERTIFICATE----

   Info

   The first line of the certificate must contain only -----BEGIN CERTIFICATE-----, and the last line must contain only -----END CERTIFICATE-----.

5. In the WebSphere user account repository, create a new user whose user name matches the first CN value of the subject field in client.cer certificate.
   For example, to configure the user name for the following certificate, use production.company.com as the user name.
   
   

   CN = production.company.com
   CN = Services Department
   O = Company Inc.
   L = Toronto
   S = Ontario
   C = C

6. If the WebSphere user account repository is configured for Active Directory or LDAP, create the user in Active Directory or LDAP. If the user account repository is configured for an internal file repository, create the user using the Integrated Solutions Console.

   Info

   If you create the new user in LDAP, you must enter the user name that you used for the WebSphere user account repository in the Full Name attribute. Do not enter values for the First Name and Last Name attributes.

7. If your WebSphere configuration uses a LDAP user account repository, you must update the certificate mapping for repository:

   1. Launch the Integrated Solutions Console.

   2. Click the Security field, then click Global security.

   3. In User account repository, click Configure.

   4. In Related Items, click Manage repositories.

   5. Select the repository that represents the LDAP user account repository.

   6. In the Certificate mapping field, select CERTIFICATE_FILTER.

   7. Set the Certificate filter to cn=${SubjectCN}.

8. Restart all WebSphere processes.

9. Reconfigure and redeploy the application.

10. Verify the changes.

Two-way SSL authentication is configured for inbound traffic to the WAS.