Friday, May 21, 2010

Eliminating WebSphere Application Server 6.x & 7.x web server plugin with another load balancer

There are situations where you would forego installing a web server in front of the application server(s) for WebSphere Application Server 6.x & 7.x. To make it work, the following three steps need to be taken:

1. Add the following web container custom properties for each application server:

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

This makes sure that the HTTPResponseHeader.sendRedirect() API call will send back a URL using the port in the host header of the request message rather than the HTTP/S port that the application server listens to. The default behavior of the application server doesn't match the default behavior of the web server plugin who AppServerPortPreference setting in the plugin-cfg.xml file is hostHeader by default.

2. (Optional) Add the RemoveServerHeader = true custom property to each application server's inbound HTTP transport channel for both the secure (HTTPS) and unsecure transport chains. By default the transport chains are named WCInboundDefault for HTTP and WCInboundDefaultSecure for HTTPS. This removes the response message header saying that the server is a WebSphere Application Server. Since the web server is no longer masking this with its own server header, it is best to eliminate this for security purposes.

3. Assuming the web server being replaced is the IBM HTTP Server and it was serving HTTPS traffic, you need to convert the CMS keyfile (filename suffix of kdb) used by the web server to JKS and set the application server's HTTPS port to use the new JKS file:

a. Run "gsk7cmd(.sh) -keydb -convert -db key.kdb -pw [password]
-old_format cms -new_format JKS" assuming the keyfile name is key.kdb

b. Review the converted JKS file and eliminate any expired certificates or certificates that weren't the default certificate being served in the original kdb file because unlike CMS keyfiles, JKS keyfiles don't have a way to flag which certificate is the default certificate.

c. Copy over the JKS file to a common relative location on the deployment manager and application server boxes (e.g., /opt/WebSphere/AppServer/profiles/Dmgr01/etc and /opt/WebSphere/AppServer/profiles/AppSrv01/etc)

d. In 6.x, create a new SSL repertoire, set the JKS file as both the key and trust files, and point it to the relative location of the JKS file (e.g., ${USER_INSTALL_ROOT}/etc/key.jks). In the application server's WCInboundDefaultSecure transport chain, change the SSL transport channel to use the newly created SSL repertoire.

e. In 7.x, create a new keystore and point it to the relative location of the JKS file. Create a new SSL configuration and assign the newly created keystore as both the trust store and keystore. In the application server's WCInboundDefaultSecure transport chain, change the SSL transport channel to use the newly created SSL configuration.

f. Make sure the nodes are synced and restart the application server(s).

4. In the new load balancer which will replace the web server plugin, make sure to enable sticky sessions (a.k.a. session affinity).

No comments: