Date Created: Mon 14-Mar-2011

Related Document Categories:

Get my WebSphere Application Server course here >>

This document is out of date, it was written for WAS 6.1 and WAS 7.

You can purchase a more up to date module at

WebSphere SSL Secrets – Part 1
How to Install and Configure SSL
between IBM HTTP Server (IHS)
and WebSphere ND

The Complete Guide...

Written by: Steve Robinson

Purpose of this document
My intention is to cover in as much detail as I can how to configure SSL between IBM HTTP Server and WebSphere Application Server. I will be using many screen shots to show visually what I am doing, along with some simple notes in text to augment the images. I believe the content is quite easy to understand and I welcome any feedback on how to make this article better.

Installing the Default Application EAR file
First of all we require that a Configured Cell exists. I am assuming that you have already installed Websphere 7 ND and that you are familiar with the concept of a WebSphere Cell.
I have created a standard Cell configuration with a Deployment Manager Node and Application Server Node. This means I have two profiles. One profile for the Deployment Manager (DMgr) and one for the application server node. On this cell I have created a cluster using a single node. The cluster is called cluster01 and there are two member servers (clones) called server01 and server 01.
Since our goal is to understand how to install SSL between IHS and WebSphere, we need an application to test our SSL configurations and so we are going to use good old snoop servlet. The snoop servlet comes packaged as an EAR file called the Default Application and comes with WebSphere and is a great tool for testing your WebSphere configuration,

We will now use the Administrative console to install the Default Application EAR file.

Log into the admin console and select New Application

Then click “New Application” as shown below

Select Remote file system and brows for the Default Application

In my example below I am browsing the file system of the Deployment Manager. The reason I do this, is because is I have created a horizontal cluster design and my application Server node, may not be on the same physical machine as the Deployment Manager. The Dmgr has the default application.

As you can see the DefaultApplication.ear file is located in the installable apps folder.

Click “OK” to continue and in the next screen we will use the fast path option, as we will accept all the application resource binding requirements.

We need to ensure that on the Install New Application screen that we make sure that we install to the cluster.
Accept all other defaults, and click “Next” until the finish. Click “Save” to persist the application configuration. Our deployment is now complete.
We can now navigate to the WebSphere enterprise applications section of the Right-Hand-side of the Admin console panel as shown below.

You will then be presented with a list of installed applications.

Select the DefaultApplication.ear and click Start as shown above.
One the application has be fully started, you can navigate using our browser to
http://<hostname>1:9080/snoop/ for example:

You can see in the image above the snoop servlet reports information about the host it is running on. We have now proven that we can connect to port 9080 the default http port of the server01 clone.
What we wish to do now is install and configure IBM HTTP Server so we can use port 80 and then configure SSL so we can use port 443.
Before we go further is interesting to see no workload management in operation, we have accessed the web container of server 01. To get to web container on server02 we need to use the following URL: http://<hostname>:9081/snoop/ for example

To find out what a server’s default http port is you can navigate to the Port section of an application server’s configuration. As shown below.

Another way to find the port by viewing the file serverindex.xml file of the application server node for example

view /var/apps/wasnd7/profiles/Appsrv01/config/cells/localhostCell01/nodes/localhostNode01/serverindex.xml as shown below.

Downloading and installing IBM HTTP Server.

IHS is free to download from IBM and at the time of writing the URL immediately below can be used to locate the IHS downloads.
You will need to register if you do not already have an IBM website ID. This is a requirement to download IHS.

At the time of the writing of this mini article, the IBM HTTP Server (IHS) is currently at version We will not need to upgrade IHS for this exercise; you can search for my article on how to upgrade IHS.

Download IHS and un-tar into the root of the WebSphere binaries you used to install WebSphere ND.

Note: You may find that depending on how you got WebSphere ND binaries that you may already have a version of IHS, it is ok for you to use that version.#
We are going to install IHS using the Graphical Installation Wizard.

Once you have downloaded ihs.7000.linux.ia32.tar file upload it to your Linux server and un-tar the folders as mentioned above.

Installing IHS
My binaries are located: /var/apps/wasnd7_install/lin_ia32/IHS
My binaries are located: /var/apps/IHS6_Install/IHS_6.1.0.0


Note: If ./install does not work, this is because you are using Centos and By default, CentOS 5 has the SE Linux feature set to "enforcing", this may not be the what you want, you can disable SE Linux temporarily by using the following command.

usr/sbin/setenforce 0

Tip: You can edit the IHS installation script to not redirect the Java Console (DONT_REDIRECT=true) and thus you will be able to see errors in the installation process for example
Error loading: /var/apps/IHS6_Install/IHS_6.1.0.0/JDK/jre.pak/repository/ cannot restore segment prot after reloc: Permission denied
The error shown above is an example or SE Linux enforcing which is stopping the installation process.

Click Next and Accept license, the Next again until you come to the screen where you can chose the installation location.

I have chosen to leave the default ports.

I use wasadmin/wasadmin for the IHS administration password. We will need to remember these settings if we choose to later administer IHS from the Administration Console.

On the Setup HTTP Server Administration Server screen we do not wish to configure a IBM HTTP Administration server.

Click Next until you get a summary screen, if you are happy with the configuration, click next again and the wizard will start to install IHS.
One the install is finished we will start and stop IHS to ensure that it is running properly.

My installation of IHS is located at: /var/apps/ihs7/bin

Type the following command to start IHS

./apachectl start

Uou should now be able to navigate to port 80 and see the IBM HTTP Server welcome screen by typing in the following URL: http://<hostname>/ For example:
If you see the welcome screen as shown below, then we know IHS is installed ok.

We can now stop IHS, by issuing the command:

./apachectl stop

Note: If you want to be thorough you can view the logs in the <ihs_root>/logs folder to see if there are any errors.
We are now ready to install the Websphere Plugin, so we can have our traffic hitting port 80 and IHs along with the Plugin, will workload manage our requests across our servers.

Downloading the Websphere Plugin

There is a link on this landing page to the Websphere Plugin downloads page.

Currently there is no plug-in for version 7. I have chosen to use the 6.1 Plug-in:

The download is called: trial_plugins_linux.ia32.tar.gz

Type the following commands
gunzip trial_plugins_linux.ia32.tar.gz
tar -xvf trial_plugins_linux.ia32.tar

We can now navigate into the plugins folder and run the graphical installer.

I extracted by installation to: /var/apps/Plugin_Install/plugin


Tip: As with the IBM HTTP Server install script you can edit the plugin install script to not redirect the console as it is installing so you can see potential installation errors as they are happening.

Tip: I recommend downloading and applying the latest fix pack for IHS.

You will require the latest fix pack installer

You can search for tips on how to install and run a the new update installer and how to upgrade IHS.

Click Next, until you come to the Web Server Configuration page as shown below

Select IBM HTTP Server v6 or V6.1

Our installation of IHS is on the same machine as WebSphere, so we can select WebSphere Application Server machine (local)
On the next screen we can type the location of where the Plugin will be installed. It is a common practice to install the Plugin into <ihs_root>/Plugins for example: /var/apps/ihs6/Plugins . Click Next to continue.

In the next screen we type in or browse for the location of WebSphere

This is so the Plugin wizard can detect where the WebSphere plugin-cfg.xml is located. I have chosen /var/apps/wasnd7 which is where my Websphere root is. Click Next.

On the next screen we are asked which profile we wish to configure with the Plugin, we will use the Deployment Manager.
On the next screen we point the Plugin wizard to the location of the IHS conf directory so it can modify the httpd.conf file.

In my example I have used <ihs_root>/conf/httpd.conf for example /var/apps/ihs6/conf/httpd.conf

On the Next screen we get to choose the location of the plugin-cfg.xml file. Now since after this install we are going to set up a WebServer in the admin console so we can set this later, for now just leave it as it is so we can tell what part of the httpd.conf is being altered.


Click Next until the Wizard starts the Plugin installation.

When the installation process has completed, we need to look at the httpd.conf file and see what changes the installation has made.
As you can see by this snippet below which was taken from my httpd config file, that the Plugins module has been added and also the location of the plugin-cfg.xml file.

LoadModule was_ap20_module /var/apps/ihs6/Plugins/bin/
WebSpherePluginConfig /var/apps/ihs6/Plugins/config/webserver1/plugin-cfg.xml

Configuring a Web Server Definition
We are now going to re-log into the WebSphere admin console and add a new Web server definition.
Log into the Administrative Console and navigate to the Server Types category of the Servers section in the Right-Hand side panel and click Web Servers as shown below.

Click New as shown below to create a new web server definition.

On the next page type “webserver1” into the Server name field and then click Next.

Click “Next” again to skip the IHS template page. On the next page you will be required to fill in some information about the location of IHS and the Plugin. As you can see below, I have filed in the appropriate locations. Make sure that you set ours accordingly to our installations earlier in the article.

Click “Next” until the wizard is complete, and then ensure that the new web server definition is saved and persisted.
Once saved, you will be taken to a list of web servers as shown below.

Click on the websever1 link so we can inspect the actual configuration.

Click on Plugin properties to review the settings. As you can see in the image below, the web server knows where the Plugin needs to be propagated. This needs to match with what is in IHS as seen above when we evaluated the httpd.conf. Please ensure that the path/location is correct. Each time we make a change to our Cluster/app Servers, we need to propagate the WebSphere plugin-cfg.xml file over to IHS and restart IHS.

We now need to evaluate the virtual host configuration of the WebSphere Web Container. To change virtual host configuration, click on the virtual hosts link of the Environment section located with the Right-Hand-Side panel of the admin console as shown below.

You will then be presented with a list of named WebSphere virtual hosts.

Click default host

Click Host_Aliases to review the ports listed. We need to ensure that each port of each application server (clone) in our cluster is listed and also the port in which IBM HTTP Server is listening on. This information together with application context roots, defines what will be generated in the plugin-cfg.xml file. This will be generated by WebSphere and then propagated over to IHS, when required.

Mapping ModulesTo Web Servers

Before we can test our Default Application (snoop servlet) we need to ensure that the application’s web module (WAR) is bound to the new web server definition.
To change the deployed Default application EAR file we need to navigate to the Application Types category of the Applications section of the Right-Hand-Side panel in the admin console as shown below.

Click on the DefaultApplication.ear file as shown bellow.

In the Enterprise Application configuration screen click Manage Modules link located in the Modules section as shown below.

Select webserver1 and apply it to the web module of the application as shown below. This will create a URI for the Plugin to map requests from IHS to the Web Application running in Websphere.

Click OK and save changes to complete.

We are now going to tell WebSphere to re-generate the Plugin and propagate to IHS. One gain navigate to the Web Server’s list screen and then click Generate Plug-in, and then Click Propagate Plugin.

Note: Propagate in our example means the DMgr’s version of the Plugin-Cfg.xml is copied to the appropriate location where IHS is looking for the Plugin.

Is copied to:

/var/apps/ihs6/Plugins/config/webserver1/plugin-cfg.xml on the Web server computer

We can now go and look at the updated Plugin-Cfg.xml file in IHS.

Type the command:
view /var/apps/ihs6/P

Below is a snippet of the plugin-cfg.xml file

<Config ASDisableNagle="false" AcceptAllContent="false" AppServerPortPreference="WebserverPort" ChunkedResponse="false" FIPSEnable="false" IISDisableNagle="false" IISPluginPriority="High" IgnoreDNSFailures="false" RefreshInterval="60" ResponseChunkSize="64" VHostMatchingCompat="false">
<Log LogLevel="Error" Name="/var/apps/ihs6/Plugins/logs/webserver1/http_plugin.log"/>
<Property Name="ESIEnable" Value="true"/>
<Property Name="ESIMaxCacheSize" Value="1024"/>
<Property Name="ESIInvalidationMonitor" Value="false"/>
<Property Name="ESIEnableToPassCookies" Value="false"/>
<Property Name="PluginInstallRoot" Value="/var/apps/ihs6/Plugins/"/>
<VirtualHostGroup Name="default_host">
<VirtualHost Name="*:9080"/>
<VirtualHost Name="*:80"/>
<VirtualHost Name="*:9443"/>
<VirtualHost Name="*:5060"/>
<VirtualHost Name="*:5061"/>
<VirtualHost Name="*:443"/>
<VirtualHost Name="*:9061"/>
<VirtualHost Name="*:9044"/>
<VirtualHost Name="*:9062"/>
<VirtualHost Name="*:9081"/>
<VirtualHost Name="*:9444"/>
<VirtualHost Name="*:9045"/>
<ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="cluster01" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60">
<Server CloneID="14f9snmv4" ConnectTimeout="5" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="localhostNode01_server01" ServerIOTimeout="60" WaitForContinue="false">
<Transport Hostname="localhost" Port="9080" Protocol="http"/>
<Transport Hostname="localhost" Port="9443" Protocol="https">
<Property Name="keyring" Value="/var/apps/ihs6/Plugins/config/webserver1/plugin-key.kdb"/>
<Property Name="stashfile" Value="/var/apps/ihs6/Plugins/config/webserver1/plugin-key.sth"/>
<Server CloneID="14f9snv2s" ConnectTimeout="5" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="localhostNode01_server02" ServerIOTimeout="60" WaitForContinue="false">
<Transport Hostname="localhost" Port="9081" Protocol="http"/>
<Transport Hostname="localhost" Port="9444" Protocol="https">
<Property Name="keyring" Value="/var/apps/ihs6/Plugins/config/webserver1/plugin-key.kdb"/>
<Property Name="stashfile" Value="/var/apps/ihs6/Plugins/config/webserver1/plugin-key.sth"/>
<Server Name="localhostNode01_server01"/>
<Server Name="localhostNode01_server02"/>
<UriGroup Name=" default_host_cluster01_URIs ">
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/snoop/* "/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hello"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hitcount"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsp"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsv"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsw"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/j_security_check"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/ibm_security_logout"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/servlet/*"/>
<Route ServerCluster="cluster01" UriGroup=" default_host_cluster01_URIs " VirtualHostGroup=" default_host "/>

You see by reviewing the setting in red/bod that the Plugin uses the XML to determine routing paths for http traffic. Because our cluster has two application servers, workload management will occur via the Plugin and Websphere and so each HTTP request on port 80 from IHS will route in a round robin fashion to each of clones i.e. 9080, then 9081, then 9080, then 9081 etc.

We can now restart IHS and test the snoop servlet can be accessed via port 80.

When we navigate to snoop using the URL we used previously in the article we can scroll down to see which application server is loading the servlet. The snippet below shows the initial server being server01.

If you refresh the browser the snoop servlet will be reloaded and the Plugin will “workload manage” between the clones of our cluster. Since we have two clones in our cluster the next server will be server02. The screen capture below shows an example of server02 being hit.

We have now achieved workload management using IHS, the WebSphere Plugin and two clones within a single WebSphere cluster.
Configuring SSL for IBM HTTP Server (IHS)

What we now want to do is get to the heart of this article and configure IHS to accept SSL. This will allow client browsers to use HTTP/S with IHS.
First we need to run the IHS ikeyman utility to generate a new self signed certificate. This tool requires XWindows to be running for this demo as we are using the Graphical interface.

<ihs_root>/bin/ ikeyman

When IBM Ikey Management tool has loaded click Key Database File >> New from the menu as shown below

Select CMS as The Key database type

Then click OK and you will be prompted for password to secure your new key ring as shown below.

Click “OK” and you will be reminded that a stash file has been created. This file will be used later by IHS to gain access to the key ring.

To create a new self-signed certificate you need to select Personal Certificates from the Certificate Type drop down as shown in the image below and then click the New Self Signed button to start the creation of a new self signed certificate.

You will prompt to fill in the certificate details as seen below. This can be as detailed as you like. Ensure you use a label that you can recognise if there were more than one in your key ring.

Click “OK” to generate the certificate; you will see it listed when you return to the main panel.
Tip: As shown below it is a good habit to ensure that you have saved the current password to your stash file before exiting the key ring.

You can now exit the ikeyman tool

What we now need to do is add a virtual host to the IBM HTTP Server configuration so that we can use SSL.

./apachectl stop

If you get the following error
[Sun Sep 20 17:58:49 2009] [error] (EAI 2)Name or service not known: Failed to resolve server name for (check DNS) -- or specify an explicit ServerName
It is because I am using a virtual server and it cannot resolve the ip address to fix it I add this line to /etc/hosts localhost.localdomain localhost

Configuring The httpd.conf file for SSL

Below is an example of a virtual server that facilitates SSL. I will not go into detail as this information is freely available on my site and also other Apache sites.
DocumentRoot "/var/apps/ihs6/htdocs/en_US"
SSLServerCert IHS_SSL_Key
KeyFile "/var/apps/ihs6/bin/key.kdb"
ErrorLog logs/https-error_log
SSLV2Timeout 100
SSLV3Timeout 1000

If you restart IBM HTTP Server, you will now be able to access IHS via SSL. We will now test…

If we then try to navigate to https://<hostname>/snoop we wi lget the following 500 error.

This error can only be resolved by fixes to the Web server software. It is not a client-side problem. It is up to the operators of the Web server site to locate and analyze the logs which should give further information about the error.

OK, IBM HTTP Server is reporting a problem, let’s look at the logs.
By looking into the Plugin logs which are located in /var/apps/ihs6/Plugins/logs/webserver1 as per our configuration of the Plugin previously. You can see in red below that the application cannot be found on this request.
[Sun Sep 20 19:13:12 2009] 0000748b 06d2eb90 - ERROR: lib_stream: openStream: Failed in r_gsk_secure_soc_init: GSK_ERROR_BAD_CERT(gsk rc = 414)
[Sun Sep 20 19:13:12 2009] 0000748b 06d2eb90 - ERROR: ws_common: websphereGetStream: Could not open stream
[Sun Sep 20 19:13:12 2009] 0000748b 06d2eb90 - ERROR: ws_common: websphereExecute: Failed to create the stream
[Sun Sep 20 19:13:12 2009] 0000748b 06d2eb90 - ERROR: ws_server: serverSetFailoverStatus: Marking localhostNode01_server02 down
[Sun Sep 20 19:13:12 2009] 0000748b 06d2eb90 - ERROR: ws_common: websphereHandleRequest: Failed to execute the transaction to 'localhostNode01_server02'on host 'localhost'; will try another one
[Sun Sep 20 19:13:12 2009] 0000748b 06d2eb90 - ERROR: lib_stream: openStream: Failed in r_gsk_secure_soc_init: GSK_ERROR_BAD_CERT(gsk rc = 414)
[Sun Sep 20 19:13:12 2009] 0000748b 06d2eb90 - ERROR: ws_common: websphereGetStream: Could not open stream
[Sun Sep 20 19:13:12 2009] 0000748b 06d2eb90 - ERROR: ws_common: websphereExecute: Failed to create the stream
[Sun Sep 20 19:13:12 2009] 0000748b 06d2eb90 - ERROR: ws_server: serverSetFailoverStatus: Marking localhostNode01_server01 down
[Sun Sep 20 19:13:12 2009] 0000748b 06d2eb90 - ERROR: ws_common: websphereHandleRequest: Failed to execute the transaction to 'localhostNode01_server01'on host 'localhost' ; will try another one
[Sun Sep 20 19:13:12 2009] 0000748b 06d2eb90 - ERROR: ws_common: websphereWriteRequestReadResponse: Failed to find an app server to handle this request
[Sun Sep 20 19:13:12 2009] 0000748b 06d2eb90 - ERROR: ESI: getResponse: failed to get response: rc = 2
[Sun Sep 20 19:13:12 2009] 0000748b 06d2eb90 - ERROR: ws_common: websphereHandleRequest: Failed to handle request

The reason is that IHS does not know how to speak to WeSphere via SSL.

Configure SSL Between IHS and WebSphere Web Container

Navigate to the Web Server Definition in the admin console and click to edit the configuration.

The plug-in keyring file is propagated from




on the Web server computer.

Note: You can also change the default password by clicking manage certificates. The default password just like in previous versions is WebAS.
The plugin-key.kdb (Key Ring) and plugin-in.sth (Password stash) are now updated on the webserver1 definition as shown the file system image below.

We can now restart IHS and when you load snoop via SSL, you will get a screen similar to the following below.

As you can see above the port for IHS is 443 which is what the client is using, however the application is being served by port 9443 which is the SSL port of the application servers Web Container.
If we refresh the browser, we will see that the local port changes to 9444 as seen below.

This is because the Plugin is facilitating Workload Management because we are using Websphere ND Clustering which has two application server clones.
This concludes the lesson on how easy it is to now set-up SSL between IBM HTTP Server and WebSphere.

In previous version of WebSphere this was so much more complicated and I am sure many WebSphere administrators will be happy about how simple it is now. Another cool thing is that the entire installation and configuration process can be automated with a response files, a little scripting and some Jython.
I hope that this document has helped you understand more about configuring SSL between IBM HTTP Server and WebSphere Application Server.

If you ever need any help, email me on

Your friend,

Steve Robinson

Extra Information

A new feature of WebSphere 7 is that you can also have the admin console generate IHS virtual servers. These next few slides are for reference and are not required in our demonstrations.

As sown above we are going to configure the Virtual server definition for this WebServer. Click New as shown below.

As shown below, on the Virtual host screen we need to select Name-based or IP-based virtual host. Then click Next.

© 2009 Steven Robinson – All rights reserved

Have you read my book?
The WebSphere Application Server 7.0 Administration guide

Get my WebSphere Application Server course here >>

Steve Robinson - IBM Champion 2013

About Me

Steve Robinson has been working in IT for over 20 years and has provided solutions for many leading brands around the world. Steve specialises in JEE, DevOps and Thought Leadership.

In January 2013, I was awarded the prestigous 'IBM Champion' accolade.

  • Linked In
  • Twitter
  • About Me
  • Contact Me

Read my books?

IBM WebSphere Application Server 8.0 Administration Guide

IBM WebSphere Application Server 8.0 Administration Guide

WebSphere Application Server 7.0 Administration Guide

WebSphere Application Server 7.0 Administration Guide


  • WebSphere Courses


WebSphere Categories

Other Categories