IBM HTTP Server Certificate Resources

More troubles with IBM HTTP Server Certificates. We have one physical server, with an IBM HTTP Server and one physical instance of Websphere 6.1 running. I want requests to come in through 2 separate URLs, be routed to the one HTTP Server, then sent to the proper App Server node (same application context though) based on the URL/Virtual Host. AND, I want all of this to happen with SSL. Fun, huh?

I wanted to share more links that I found that helped me out...

• GSK_ERROR in Plugin Log
• Merging plugin-cfg.xml files from multiple nodes

I've also once again had difficulty with WSAdmin and SSL... make sure that if you're having certificate issues with WSAdmin (or starting and stopping Websphere) to run it from the command line and not some other way. It will show you the output of the certificate and allow you to install it. If only the plugin behaved this way.

Setting up Acegi, CAS, Kerberos/SPNEGO and Websphere 6.1 Part TWO

Continued from part one


Step Four: Setup IBM HTTP Server and Websphere Plugin to Websphere Server 6.1

In order to prepare for SSL on Websphere, a web server front end should be used. Apache, IIS, etc can all be used, however IBM HTTP Server is the easiest setup and comes installed with WAS. Documentation for this setup is surprisingly unclear and difficult to locate. If you are unfamiliar with WAS or unfamiliar with this type of setup, you may be at a loss of even knowing where to start. Here are some hints.

1. IBM HTTP Sever and Websphere Plugin is installed with WAS 6.1 by default.
2. Most of the installation and configuration for the webserver can be done through the Websphere Administrative Console under Servers à Webservers.
3. Create the new Web Server through the admin console, make sure you can access it, and make sure that WAS can connect to the HTTP Server administrator.
4. If you are familiar with Apache Web Server, IBM HTTP Server is based off of Apache. So, Apache documentation may be helpful if changes need to be made to the httpd.conf file.
5. Once you've got the HTTP Server up and running, generate the plug in file and propagate the plug in file to the HTTP Server.

Gotchas:

• If you are setting up SSL, just get the web server running first. It's helpful to use WAS's snoop servlet to test the configuration.
• If your app is already installed, you will need to map the module to the server. Do this from the Admin Console, Applications à Your Application à Manage Modules. You will see your app, and you should see your web server in the server column. If not, you can map it on that screen.
• When setting up CAS on Websphere, if you access the CAS login screen, you may get a JSP error. Details of this can be found here and the solution provided worked. Yes, you will need to rebuild CAS.

Step Five: Setup SSL on Websphere 6.1

Setting up SSL on Websphere is a nightmare compared to setting up SSL on Tomcat. Very helpful in the SSL setup process was the following document: SSL, certificate, and key management enhancements for even stronger security in WebSphere Application Server V6.1. Otherwise, documentation of setting up SSL on Websphere was very hard to find. The server was set up with a self-signed certificate in the development environment. Like web servers, certificates can be generated and managed in WAS's Admin Console, under Security à SSL certificate and key management. For CAS and Acegi to work properly, there needs to be trust at every level – between the web server and the app server and vice versa, and between your application and CAS.

For this project, first SSL was set up on Websphere in order to make CAS available via SSL. CAS was deployed onto the Websphere server, and was accessed via the HTTP Server. The application itself was still running on Tomcat locally, but the CAS URLs were changed from the Local CAS to the Websphere (remote) CAS. On the HTTP Server side, a Virtual Host needed to be set up (through WAS Admin Console) linking the 443 port from the app server to the web server. A key store had to be specified at this point.

Also under the web server, a global directive needed to be specified with the (server IP Address):443 as the listen port. A key store had to be specified here as well. When setting these up through the admin console, WAS will automatically generate and regenerate the httpd.conf file. If in doubt, also regenerate the plug in file and populate it down to the HTTP server. Restart the HTTP server after these changes are made.

Gotchas:

• When in doubt, if you are getting a "unable to find valid certification path to requested target" error, use the utility provided here to resolve the issue.
• While most documentation regarding CAS and Acegi setup suggest using cacerts as a truststore, Websphere will occasionally throw errors when doing this. Either use one of the p12 format truststore/keystores or comment out the truststore variable all together.
• This is a difficult process. Turn on Websphere tracing and pay attention to Websphere error logs to work out all of the problems.

Step Six: Set up CAS for SPNEGO / Kerberos Authentication

This step goes hand in hand with Step five, and they can be done together. JA-SIG already has some excellent documentation on setting up SPNEGO. If all of the steps are followed, you should be able to log into CAS without a login screen. Like with the Websphere SPNEGO setup, you will have to make sure that your client browser is properly configured.

Gotchas:

• None! This works cleanly out of the box.

Step Seven: Install Application with Acegi and access CAS with SPNEGO.

Once all of the previous steps are complete, the final step is to install the application and access CAS for logging in without interaction.

Gotchas:

• Since Acegi requires filtering on URLs where the page does not actually exist, Websphere 6.1 will not handle this properly. To fix this, a custom property in the Web Container must be set. The property is com.ibm.ws.webcontainer.invokefilterscompatibility and it should be set to true. More details can be found here.
• CAS would not authenticate properly with Websphere version 6.1.0.13. Upgrading to 6.1.0.15 did resolve the issue.