5.3 Configuring WebSphere for SSL

---

5.3 Configuring WebSphere for SSL

In 5.2, "Configuring WebSphere with LDAP" on page 117 we have ensured that WebSphere communicates with the LDAP server over an encrypted SSL channel. However, by default, all communication between the end-user´s browser and the WebSphere Portal Server (normally, via an intervening Web server) will occur over normal HTTP. All communication (including user names and passwords) will be in the clear. It can be relatively simple for a malicious hacker to intercept this traffic and use it in an attack. This is particularly true since in our environment we are assuming that the systems are not being secured at the network level by a firewall. We therefore must take care to ensure that all traffic passes "over the wire" in an a securely encrypted form. Also, we must make sure that insecure ports are not left open to allow alternate avenues of attack.

For further information on securing WebSphere, refer to sections 10-10, 10-11 and 10-12 in Chapter 10, "Administering WebSphere security", in the redbook IBM WebSphere V5.0 Security WebSphere Handbook, SG24-6573.

5.3.1 Prerequisite tasks

Before continuing with the configuration steps for this task, it is necessary to ensure that the following configuration task (together with its prerequisite installation tasks) has been carried out:

• On the Application Node

  Configuration of WebSphere with LDAP as per 5.2, "Configuring WebSphere with LDAP" on page 117.

5.3.2 Configuring the Web server for SSL

The first precaution in securing communication is to configure the Web server for SSL.

Creating an SSL certificate for the Web server

For the Web server to communicate with SSL, it will require a valid SSL certificate. For the moment, we will choose to use a self-signed certificate. Normally, you would obtain a publicly-accessible certificate from a trusted Certificate Authority. For the steps to request, obtain and use such a certificate, please refer to section 10.9.2, "Requesting a certificate signed by a CA" in the above-mentioned redbook.

On the Application Node, go to Start -> Programs -> IBM HTTP Server 1.3.26 -> Start Key Management Utility. We need to create a new key file, so select Key Database File -> New. Ensure that the Key Database Type is set to CMS key database file. Type ihs_certs.kdb as the file name. Set the location to C:\program files\IBMHttpServer\conf. Click OK. Set the password (in our environment, we have chosen to use WebIHS). Enable the checkbox for Stash the password to a file. Click OK.

Figure 5-25: Setting the password for a key ring database file

An information message will appear stating the file name where the password has been saved. Click OK. Select Personal Certificates from the drop-down list. Click New Self-signed. Set the key label to IHS_SSL. Ensure version is set to x509 v3, keysize is set to 1024, common name is set to the fully qualified host name, organization is set to ibm.com and country is set to US.

Figure 5-26: Properties for IHS_SSL self-signed certificate

Click OK.

Figure 5-27: IHS Personal Certificates

Verify that the certificate labeled IHS_SSL is highlighted under the Personal Certificates category. Click Extract Certificate. Ensure that data type is set to Base64-encoded ASCII data. Ensure the location is C:\Program Files\IBMHttpServer\conf\. Type in IHS_SSL.arm as the certificate file name. Click OK.

Figure 5-28: IHS_SSL Extract Certificate dialog

Exit the key management utility.

Changing the Web server administrator password

We now have to make various configuration changes for IBM HTTP Server. Before we can do so, however, it will be necessary to set up an administrative user for the IBM HTTP Server.

On the Application Node, open a command prompt and change to C:\program files\IBMHttpServer directory (IHS root). Set up the HTTP administrator password with the command.

    htpasswd -c conf/admin.passwd ihsadmin 

Type in sah309r as the password (the password in our environment).

Figure 5-29: Setting IHS Admin password

Changing the Web server configuration

We will now configure IBM HTTP Server to communicate using SSL.

Start IBM HTTPServer/Admin server if not already started.

Start a browser session and go to http://localhost. Click Configure Server. You will be prompted for the user name and password created. Click OK.

Expand Basic Settings -> Core Settings in the left pane. Ensure the Server Name contains a valid fully-qualified host name. If it does not, enter the relevant value and click Submit at the bottom of the window.

Figure 5-30: Verifying HTTP hostname

Expand Basic Settings -> Advanced Properties. In the Specify additional ports and IP addresses section, click Add.

Enter 443 in the Port text area.

Figure 5-31: Setting the SSL server port

This is the default server port for SSL connections.Click Apply then click Submit at the bottom of the window.

Expand Basic Settings -> Module Sequence. This presents a list of modules loaded by the IBM HTTP Server and should include the IBM WebSphere AppServer module, which is probably at the top of the list.

Figure 5-32: HTTP Module Sequence

It is necessary to add the IBM SSL module. Click Add. From the Select a module to add drop-down list, select ibm_ssl(IBMModuleSSL128.dll).

Figure 5-33: Adding IBM SSL module

Ensure that the Module dynamic link library is set to modules/IBMModuleSSL128.dll. Click Apply. This will add the module to the list. Click Submit.

Every operation so far has been performed at the Global level. Now a new VirtualHost will be created specifically for SSL connections.

Expand Configuration Structure -> Create Scope. Select VirtualHost from the first drop-down list. Enter the name or IP address of the Application node in the Virtual host name text area; in our environment this is m23x2896.itso.ral.ibm.com.

Figure 5-34: Creating a new virtual host

Enter 443 in the Virtual host port text area. Enter the fully-qualified hostname in the Server name field, in our environment: m23x2896.itso.ral.ibm.com. For the Server path field, enter the path to the <ihs_root>/htdocs directory. Click Submit. A new VirtualHost entry should appear in the right-most frame.

Figure 5-35: Virtual Host definition

Expand Security -> Server Security. Ensure the scope is set to Global. If not, click Scope and select Global. For the Enable SSL radio buttons option, click Yes. Enter the path and name of the key store (ihs_certs.kdb) created with the ikeyman utility in "Creating an SSL certificate for the Web server" on page 143.

Enter an SSL version 2 session ID timeout of 100. Enter an SSL version 3 session ID timeout of 1000. Click Submit.

Figure 5-36: Enabling Server Security

Select Security -> Host Authorization. Ensure the Scope is set to the new VirtualHost defined previously, in our environment: m23x2896.itso.ral.ibm.com. For the Enable SSL radio buttons option, click Yes. Click Submit.

Figure 5-37: Enabling Server Security

Restart the IBM HTTP Server. This can be performed from the command line, by clicking the Restart Server icon in the top right corner of the window or from the Windows Services application.

Figure 5-38: Restart server icon

If you restarted using the icon, once the server has restarted you should receive the message ADM12061: Restart request has been successfully reissued.

Testing the Web server SSL configuration

This concludes the steps to complete the IBM HTTP Server configuration for SSL. The results can be tested by loading a Web browser and entering the URL:

    https://m23x2896/ 

where m23x2896 is the ApplicationNodeName.

Note 

This is https:// not http://

A message may appear from the browser explaining that the Web browser is attempting to establish a secure link with the server. If such a message appears, confirm that you wish to continue. During the initialization of the secure connection, the IBM HTTP Server will provide a certificate to the Web browser. If this certificate has not been signed by any of the Certificate Authorities known to the Web browser, then a message may appear providing details of the certificate and asking whether the certificate should be trusted.

To see the details of the certificate provided by the server, click the View Certificate button. In the details, you will find information about the certificate itself, who issued the certificate and to whom; also, you can follow the certificate path of the issuers.

In the case of a self-signed certificate, as in our environment, the Issued to and the Issued by fields will be the same, and the certificate path only has one level indicating that the root certificate is not trusted. Realistically, these certificates should not be trusted; however, for testing purposes it should be acceptable to trust the certificate.

Proceed by accepting the certificate and the Web page should load; it should be the default content page for IBM HTTP Server.

5.3.3 Configuring WebSphere Application Server for SSL

The WebSphere Web Server Plugin does not, at this stage, have the necessary information to accept SSL encrypted traffic and pass it on to the WebSphere Application Server.

To allow for this, we need to make changes in the WebSphere Administrative Console. To do this, the default application server (server1) must be running. To check to see if it is running, we can issue the command serverStatus as shown in Example 5-1.

Example 5-1: ServerStatus command and output

 C:\Program Files\WebSphere\AppServer\bin>serverStatus.bat server1 -username wpsbind -password sah309r ADMU0116I: Tool information is being logged in file C:\Program            Files\WebSphere\AppServer\logs\server1\serverStatus.log ADMU0500I: Retrieving server status for server1 ADMU0509I: The Application Server "server1" cannot be reached. It appears to be            stopped. 

If server1 is running, you will receive the confirmation message ADMU0508: The Application Server "server1" is STARTED. If it is not running, you will receive an output message as shown in Example 5-1.

You can start the server from the programs menu. Click Start -> Programs -> IBM WebSphere -> Application Server v5.0 -> Start the Server. Alternatively, issue the command shown in the following example.

Example 5-2: StartServer command and output

 C:\Program Files\WebSphere\AppServer\bin>startServer.bat server1 ADMU0116I: Tool information is being logged in file C:\Program            Files\WebSphere\AppServer\logs\server1\startServer.log ADMU3100I: Reading configuration for server: server1 ADMU3200I: Server launched. Waiting for initialization status. ADMU3000I: Server server1 open for e-business; process id is 1968 

To access the Administrative Console window, select Start -> Programs -> IBM WebSphere -> Application Server v5.0 -> Administrative Console and a browser session will be launched. You will be prompted by a Security Alert to accept a certificate. Click Yes. Log in with the WebSphere Administrative User, in our environment wpsbind with password sah309r.

Important: 

From now on, whenever you are accessing the admin console and portal, you must use the fully-qualified host name of the Application Node. This is because the SSO we have configured is dependent on the domain name. If you do not use the fully qualified host name, every successful login will simply return to the login page.

Note 

If you want to use the Start -> Programs -> IBM WebSphere -> Application Server v5.0 -> Administrative Console shortcut to access the WebSphere Administrative Console, you must modify the shortcut's properties and change the target URL to use secure HTTP and the port 9043 (for example: https://m23x2896.itso.ral.ibm.com:9043/admin/).

Figure 5-39: Logging into WebSphere Administrative Console

You should be presented with the WebSphere Administrative Console startup page.

Figure 5-40: WebSphere Administrative Console startup page

Select Environment -> Virtual Hosts.

Figure 5-41: Updating Virtual Hosts

Click default_host. Click Host Aliases under the Additional Properties section. We are going to add a new value to the list of Host Aliases. To do so, click the New button. Type in * as the value of Host Name and 443 as the value for Port.

Figure 5-42: Adding a port

Click OK. Click the Save link in the top banner (or at the top of the window in the Messages section). Click the Save button in the Save to Master Configuration section.

Since we have changed definitions for the WebSphere Virtual Hosts, it is necessary to update the configuration file for the Web Server Plugin. Select Environment -> Update Web Server Plugin. Click OK.

Figure 5-43: Updating plug-in configuration

Verify that the message obtained is The web server plugin configuration was updated successfully. What this task does is to regenerate and re-write the configuration file for the Web Server Plugin (plugin_cfg.xml in C:\Program Files\WebSphere\AppServer\config\cells). The running Web Server Plugin process monitors the configuration file for updates and will re-parse it and update its runtime configuration. To avoid any problems, it is always advisable to wait a couple of minutes for this process to stabilize before testing the connection or restarting the server. Log out from the Administrative Console by clicking the Logout link in the top banner.

5.3.4 Configuring SSL between the Plugin and the Web container In WebSphere Application Server

The above section has addressed encryption between the requesting browser and the Web server. However, the communication between the Web Server Plugin and the WebSphere Web Container is not secure by default, even when WebSphere Global Security is enabled. It is necessary to ensure that this connection is also SSL encrypted. This will also help us to ensure that no attempt is made to bypass the secure channel (via the Web Server Plugin) by contacting the WebSphere Application Server Web container directly on its listening ports.

Configuring SSL certificate for the Web Server Plugin

On the Application Node, select Start -> Programs -> IBM HTTP Server 1.3.26 -> Start Key Management Utility. Click Key Database File -> Open. Browse to C:\program files\websphere\appserver\etc and select plugin-key.kdb. Click Open. Type in the password, in our environment WebAS. Click OK.

We used this key database file because it is the one that comes automatically configured in the plugin.xml file. Alternatively, you can create a new key database file and generate a new self-signed certificate. If you do so, you will also have to update the configuration settings for the plug-in to use your new key database file.

Extract the public self-signed certificate key, since this will be used later by the Web container peer to authenticate connections originating from the plug-in. Do this by ensuring that Personal Certificates is selected. Highlight the WebSphere Plugin Key and click Extract Certificate. Ensure the Location is set to <appserver_root>, for example, C:\Program Files\WebSphere\AppServer\etc\. Name the file plugin-key.arm. Click OK.

Figure 5-44: Extracting Plugin certificate

We also need to ensure that no attempts are made to bypass the WebSEAL server and talk directly to the Web server (via the WebSphere Plugin) running on the Portal Server. We will therefore, in a later step, enable mutual SSL authentication with the WebSEAL server and only trust the certificate generated for the WebSEAL server. So, we need to delete all the existing CAs (which are normally trusted by default). It may seem that the plug-in will now not accept any SSL communication since it will not accept any certificates signed by any CAs. However, note that the SSL negotiation is actually performed by the IBM HTTP Server, not the plug-in itself, so that will not be a problem. We will enable the Web server to only trust the WebSEAL certificate, as shown in 5.4.8, "Configuring mutual SSL: WebSEAL and IBM HTTP Server" on page 199.

Select Signer Certificates from the drop-down list, select all the existing certificates and then delete them using the Delete button.

Figure 5-45: Deleting additional Signer Certificates

You will be prompted with a confirmation message asking if you are sure that you want to delete the specified key. Click the Yes button to confirm. Minimize the key management utility because we will be using it later on.

Configuring SSL certificate for the WebSphere Web Container

As explained above for the WebSphere Web Server Plugin, we also need to ensure that no attempts are made to bypass the Plugin and talk directly to the WebSphere Web Container. We will therefore enable mutual SSL authentication between the Plugin and the Web container. This will implicitly block any communication from any other clients, since we will also configure the Web container to only trust the Plugin certificates for SSL authentication.

We have to start the WebSphere version of the key management utility. To do this, click Start -> Run. Type in the command:

    C:\Program Files\WebSphere\AppServer\bin\ikeyman.bat 

Tip 

Remember to use the correct version of the key management utility.

Select Key Database File -> Open and open the file C:\program iles\websphere\appserver\etc\DummyServerKeyFile.jks which has the password WebAS. Alternatively, create a new key database file for the Web container and a new self-signed certificate. If you do so, you will also have to update the SSL settings for WebSphere Application Server.

Highlight the Personal Certificates-websphere dummy server. Click Extract Certificate. Ensure the location is set to C:\program files\websphere\appserver\etc\. Name the file was_webc.arm. Close the key database file.

Open the C:\program files\websphere\appserver\etc\DummyServerTrustFile.jks file (in our environment, its password is WebAS). Delete all the signer certificates except for:

1. pdldap

2. websphere dummy client

3. websphere dummy server

Figure 5-46: WebSphere Application Server Key Ring database

You will have to delete them one by one. You should only have the above-listed certificates left as Signer Certificates.

Figure 5-47: Remaining Signer Certificates in DummyServerTrustFile

Exchanging public keys between the two peers

To cater for mutual SSL authentication, we need to exchange the public keys between the Plugin and the Web container.

On the Application Node, maximize the key management utility with the plugin-key.kdb file open.

Select Signer Certificates and click Add. Ensure that the data type is set to Base64-encoded ASCII data. Click Browse, navigate to the C:\program files\websphere\appserver\etc folder and select the file was_webc.arm that was created in "Configuring SSL certificate for the WebSphere Web Container" on page 166. Click Open. The dialog should look like Figure 5-48 on page 169. Click OK.

Figure 5-48: Importing WebSphere Application Server Signer Certificate into Plugin Key Ring Database

You will be prompted for a label for the certificate. Type in websphere dummy server. Click OK. Close the file and the utility.

Switch back to the key management utility with the DummyServerTrustFile.jks file open. Select Signer Certificates. Click Add. Ensure that data type is set to Base64-encoded ASCII data. Click Browse, navigate to the C:\program files\websphere\appserver\etc folder and select the file plugin-key.arm. Click Open and then click OK. Enter WebSphere Plugin Key as the label name. Click OK. You should only have four certificates as Signer Certificates as shown in Figure 5-49 on page 170.

Figure 5-49: Final Signer Certificates in DummyServerTrustFile

However, note that for certain portal configuration tasks (such as installing a new portlet) it is necessary for the WebSphere Application Server to act as a client of itself. To ensure that such communication will still be allowed, we also have to configure the certificates used by WebSphere Application Server when it acts as a client.

Remaining in this key management utility, select Key Database File -> Open. Ensure that the Key database type is set to JKS. Click the Browse button and navigate to C:\Program Files\WebSphere\AppServer\java\jre\lib\security. Change the Files type in the drop-down list to All Files (*.*) and select the cacerts file; click Open and then click OK.

You will be prompted for the password, type in changeit and then click OK. Be sure that Signer Certificates is selected from the drop-down list and then click Add. Ensure that the data type is set to Base64-encoded ASCII data. Click Browse, navigate to the C:\program files\websphere\appserver\etc folder and select the was_webc.arm file. Click Open and then click OK. You will be prompted for a label for the Signer Key you are adding. Type in websphere dummy

server as the label name and click OK. This label should appear in the list of Signer Certificates available in the file.

5.3.5 Restricting the WebSphere Application Server ports

To restrict insecure avenues of attack, we ensure that WebSphere Application Server only communicates through encrypted ports and that there are no extraneous ports left open.

Open the WebSphere Administrative Console and log in.

Tip 

If you cannot access the Administrative Console, remember that the server1 application server has to be running. You may have to start it if it is not running.

Go to Servers -> Application Servers -> server1.

In the Additional Properties section, click Web container.

Figure 5-50: Restricting Web container ports

Click HTTP transports in the Additional properties section. Select the checkboxes beside the ports 9080 and 9090 and then click the Delete button.

Figure 5-51: HTTP Transports to delete in server1 Web container

The only ports you should have left are 9443 and 9043. Both should have the SSL Enabled column set to true.

Go to Servers -> Application Servers -> Websphere_Portal -> Web container -> HTTP transports. Select the checkboxes beside the ports 9081, 9091 and 9044.

Figure 5-52: HTTP Transports to delete in WebSphere_Portal Web container

Click the Delete button. Only one port should be left. Its value should be 9444 and it also should have SSL Enabled set to true.

Go to Environment -> Virtual Hosts -> admin_host -> Host Aliases. Select the checkbox beside 9090 and then click Delete.

Go to Environment -> Virtual Hosts -> wps_admin_host -> Host Aliases. Select the checkboxes beside the ports 9091 and 9044 and then click Delete.

Go to Environment -> Virtual Hosts -> default_host -> Host Aliases. Select the checkboxes besides 9080, 80 and 9081 and then click Delete.

Remaining in Environment -> Virtual Hosts -> default_host -> Host Aliases, click New. Set Hostname to * and Port to 9444. Click OK.

Figure 5-53: Port added to default_host Virtual Hosts definition

Save the changes.

Go to Environment -> Update Web Server Plugin. Click OK to regenerate the plug-in.

To verify that the above changes have been saved correctly, open the plugin-cfg.xml file in <appserver_root> for example, the C:\program files\websphere\appserver\config\cells directory.

Confirm that the transport stanzas for any https protocol look similar to Example 5-3.

Example 5-3: Transport stanzas in plugin-cfg.xml file

 <Transport Hostname="m23x2896.itso.ral.ibm.com" Port="9444" Protocol="https"> <Property name="keyring" value="c:\program files\websphere\appserver\etc\plugin-key.kdb"/> <Property name="stashfile"value="c:\program files\websphere\appserver\etc\plugin-key.sth"/> </Transport> 

Verify that there are no transport stanzas left with Protocol="http".

5.3.6 Modifying WebSphere Web Container to use Mutually Authenticated SSL

To ensure that the WebSphere Web Container only communicates with the WebSphere Web Plugin, we now enable mutual SSL authentication. Since only the Plugin certificate is trusted by the Web container, no other unauthorized connections will be allowed. This step is optional. If you have a firewall configured appropriately, you may choose not to implement Mutual Authentication. See the restriction at the bottom of this section for a current limitation.

If you have closed the WebSphere Administrative Console, open it again. Go to Security -> SSL. Click m23x2896/DefaultSSLSettings (where m23x2896 is the <applicationNodeName>). Click the checkbox beside the Client Authentication label in the General Properties section. Click OK. Save this change.

Figure 5-54: Enabling client authentication

Restarting the WebSphere Application Servers

For all the above configuration changes made in the WebSphere Application Administrative Console to take effect, you will have to stop the application servers and start them up again. To stop the servers, you will have to issue the appropriate stopServer commands with in <AppServerRoot>/bin:

    stopServer server1 -username wpsbind -password sah309r    stopServer WebSphere_Portal -username wpsbind -password sah309r    startServer server1 -username wpsbind -password sah309r    startServer WebSphere_Portal -username wpsbind -password sah309r 

In our environment, sah309r is the password.

Note 

Once you have completed these steps, the serverStatus and stopServer commands will not work because the relevant application server will require a client certificate before it communicates over mutually authenticated SSL. These command line tools unfortunately have no means of providing the client certificate.

You will then have to have some patience since now each WebSphere restart may be quite lengthy. If you have started the WebSphere Application Servers as user-mode programs (via the command-line or the Start menu), you will be able to stop them by logging off your user session. Unfortunately, if you have started the Application Server as a Windows service, it will not be properly stopped by the Services application. So you will have to muster up even more patience because each WebSphere restart will mean a server reboot.

It is not advisable to use utilities (such as the Task Manager End Process button) to force a shutdown of the Java Virtual Machine used by a WebSphere Application Server. Such utilities do not always provide a normal termination signal to the process, and the Application Server may not be able to close in an orderly manner, which may lead to instability and loss of data.

Also, after each change, remember to wait a while for the Web Server Plugin to refresh its configuration.

5.3.7 Testing the changes

To verify that the changes have been correctly made ,you should do the following. Open a browser window. Go to the portal URL (connecting directly to the Web container) which is:

• https://m23x2896.itso.ral.ibm.com:9444/wps/myportal

Where m23x2896.itso.ral.ibm.com is the <ApplicationNodeHostname>.

You should see a Client Authentication dialog asking you to select a certificate to use when connecting. Since the browser does not have a valid certificate to present, the dialog should be empty and you will not be able to continue. Click Cancel. This has proved that the Web container has been successfully configured for mutual SSL authentication.

Figure 5-55: Client Authentication Certificate selection browser dialog

However, the Web container will accept requests that come from the IBM HTTP Server (through the plug-in), so, if we then proceed to the following portal URL:

• https://m23x2896.itso.ral.ibm.com/wps/myportal

where m23x2896.itso.ral.ibm.com is the <ApplicationNodeHostname>.

You will be prompted with a Security Alert to accept a certificate. Do so and the Portal login page will appear. Type in a valid portal user name and password, for example wpsadmin with password sah309r. The personalized Content Publishing Welcome page appears.

If, instead of using the fully distinguished host name, you use localhost or an unqualified hostname, you may encounter various errors and misbehaviors and will normally not be able to log in to the portal.

Configuring browser access to WebSphere Administrative Console

After completing the above steps, you will not be able to access the WebSphere Administrative Console because the WebSphere Application Servers are enabled to perform client authentication (this implies the use of trusted SSL certificates). Generally, the browser you connect from will not have a valid certificate to present to the server.

Note 

If you want to use the Start -> Programs -> IBM WebSphere -> Application Server v5.0 -> Administrative Console shortcut to access the WebSphere Administrative Console, you must modify the shortcut's properties and change the target URL to use secure HTTP and the port 9043 (for example: https://m23x2896.itso.ral.ibm.com:9043/admin/).

Select Start -> Programs -> IBM HTTP Server 1.3.26 -> Start Key Management Utility. Select Key Database File -> Open and browse to C:\program files\websphere\appserver\etc. Select the plugin-key.kdb file and click Open. You will be challenged for a password. Type in WebAS. Select Personal Certificates from the drop-down list. Highlight the WebSphere Plugin Key certificate and click Export/Import. Select Export Key for the action type. Select PKCS12 as the key file type. Browse to a secure temporary directory and type in was-plugin-key.p12 as the file name. Click Save and then OK.

Figure 5-56: Exporting Plugin Key dialog

Type in an arbitrary password to protect the target PKCS12 file, for example password_PKCS. Note that the key management utility gives you a hint as to the strength of this password via the graphical gauge labeled Password Strength; aim to have four or five keys showing as per Figure 5-57 on page 181.

Figure 5-57: Password protection dialog for exported certificates

You will then be prompted for the encryption type, select Weak encryption (browser compatible) and click OK. Close the key management utility.

To import this certificate for Internet Explorer and make it available as a Personal Certificate, you need to do the following:

1. Select the file just exported and right-click it.

2. Click Install PFX . The Certificate Import Wizard will start. Click Next.

3. Click Next again. Set the password for the file as password_PKCS. Click the Enable strong private key protection checkbox. Click Next.

4. Select the Place all certificates in the following store radio button. Click Browse and select Personal and then click OK.

5. Click Next.

6. Click Finish to confirm the settings.

7. Click Set Security Level. Select High. Click Next.

8. Type WAS Admin Console as "password for". Type sah309r as the password (in our environment). Click Finish.

9. Click OK. You should get a message box stating that the import has been successful.

Once you have done this, when you access the Administrative Console, you should be prompted by the browser to select a certificate to use. Always select the above certificate and you should be able to access the Administrative Console.

Important: 

You must carefully safeguard this certificate (especially in the PKCS12 file and on all machines where you have imported it). If a malicious attacker obtains it, he can potentially communicate with the WebSphere Application Server directly. Note, however, that the possession of this certificate by a malicious attacker does not imply that he will not have to bypass any other security measures taken. Remember to always use appropriate methods to secure your environment

Restriction: 

At the time of the writing of this redbook, there was a limitation with Mutually Authenticated SSL. In order to deploy portlets using the install portlets portlet or the xmlaccess deploy portlet, you will need to turn off mutual SSL first. Therefore, to deploy portlets, you will need to turn off mutual SSL, deploy your portlets then turn mutual SSL back on. To turn on mutual SSL, follow the steps in 5.3.6, "Modifying WebSphere Web Container to use Mutually Authenticated SSL" on page 176. To turn off mutual SSL, you can follow the same steps but clear the checkbox beside the Client Authentication label in the General Properties. To use the XMLAccess tool, you can also set up SSH tunneling as a workaround.

---