Troubleshooting External Web Server Issues

, ,

Configuring Lawson on an external web server is pretty straightforward…until you have issues.  The most common symptom I have run across is a 404 error when you open the web page, which typically indicates that external web server can’t find sso/sso.js.  (A quick Fiddler session will confirm that for you).  That is the first time the external web server is reaching out to the Lawson application server, so that error message indicates that you have a communication failure between the two web servers.  There can be many reasons for that communication failure, from bad plug-in files to bad certificates.  Here are just a few things to review:

  1. Make sure your modules are mapped

Navigate to WebSphere > Applications > Application Types > Websphere enterprise applications.  Select the IOS application and click “Manage Modules”.  Make sure all modules are mapped to all servers (web and application).  Do this for IOS and LawsonSecurity.  You can also check RQC and BPM for good measure.

  1. Check Virtual Hosts

Navigate to WebSphere > Applications > Application Types > Websphere enterprise applications.  Select IOS.  Under “Web Module Properties” on the right, click “Virtual Hosts”.  Make note of which virtual host IOS is using.  Then, under Environment > Virtual Hosts, click the host being used by IOS.  Make sure that your External Web Server port is in the host alias list.  NOTE: if your external web server is using the same port as your internal web server, it is best to give explicit aliases for that port.  Add an alias with the fully qualified domain for each server, and the port being used.

  1. Check your plugin-cfg.xml

Make sure the plugin-cfg.xml on your external web server looks right.  On your external web server, you should find the plugin-cfg file at <IBM Plugins Directory>/config/<Web Server Name>

It should have some basic properties.  First of all, it should contain all the virtual hosts that you just checked in step 2.  Secondly, it should contain some Uri’s specific to Lawson (not just the default WebSphere application).  Here is an example of a “bad” plugin-cfg file compared to a “good” one.

BAD – does not have all my virtual hosts

BAD – does not have any lawson-specific Uri’s

GOOD – all my virtual hosts are represented, including the host aliases I set up for duplicate ports

GOOD – there are my lawson-specific Uri’s, including that sso directory that was giving me trouble at the very beginning

The best way to resolve issues with your plug-in file is to regenerate it from your Application Server WebSphere console.  Go to WebSphere > Server Types > Web Servers.  Select your external web server and click “Generate Plug-in”.  You can’t propagate it, because it is on an external server, and it belongs to an unmanaged node.  So, make note of where the config files was saved (at the top in the Messages section).  Navigate to that location on your server and grab the file.  Copy the plugin-config.xml file and the plugin-key.kdb from that location to the plugins location noted above on your external web server.  Restart your World Wide Web Publishing service on the external web server, and test your external URL.

  1. Check the WebSphere certs

If you are having certificate issues in WebSphere, you might be seeing the 404 error in a Fiddler session, but you might also be seeing a 500 error.  Your first stop is the http_plugin.log on the external web server.  If there are certificate errors, they will be noted here.  Look for “GSK” errors.  This could mean your WebSphere certificate has expired, or there isn’t a trust between the application certificate and the external web certificate.

In WebSphere, navigate to Security > SSL certificate and key management > Key stores and certificates > CellDefaultKeyStore > Personal Certificates.  Make note of the serial number on that certificate.  Then go to the CMSKeyStore for your external web server.  Again, make note of the serial number.  If they are not matching, you’ll need to replace your external key store cert with the internal one.

To do that, first import the CellDefaultKeyStore into the web server CMSKeyStore.  In the CMSKeyStore > Personal Certificates for your external web server, click the “import” button.

In the dropdown, select the CellDefaultKeyStore, and click “Get key store aliases”.  This should populate the “certificate alias to import” down below.  Select the correct certificate to import (most likely “default”).

Give the certificate a new alias.  Click “Apply” and save changes.

Now, you need to replace the old certificate with the new one.  Under certificates, select the “old” cert and click “replace”.  Select your new cert in the “replace with” box.  You can choose to delete the old cert at this time, but it’s actually safer to delete it manually after you smoke test.  Restart the application server, or better yet, reboot!