Simply put, SSL is used to secure (encrypt) the packets exchanged between a client and a WebSphere resource, such as an application in an application server. Fortunately, a clean install of WebSphere creates many of the SSL components, which makes it fairly easy to get SSL configured in WebSphere.

For example, I deployed the FreeKB.net application to WebSphere and without having to configure SSL, I was able to get my FreeKB.net application on secure port HTTPS. So, how does this all work?

First, you want to determine the SSL configuration being used by the WC_defaulthost_secure port of the WebSphere application server. This can be done using Manage endpoint security configurations. Notice in this example that the Inherited SSL configuration is NodeDefaultSSLSettings. Inherited SSL configuration takes precedence over Specific SSL configuration for this endpoint.

Next you want to determine the keystore being used by the SSL configuration (NodeDefaultSSLSettings in this example). This can be done by viewing the SSL configuration. Let's say NodeDefaultSSLSettings is using NodeDefaultKeyStore.

Next you will want to view the certificates in the keystore (NodeDefaultKeyStore in this example). Navigate to Security > SSL certificate and key management > Key stores and certificates > the_keystore > Personal certificates. In this example, there is a certificate named default. Since there is only one certificate, we know that the default certificate is the certificate that is used to provide SSL when requesting an application from the "was2" node. In this example, the certificate is issued by dmgr.software.eng.us (the dmgr) and issued to was2.software.eng.us (the node server).

Pulling the application up in a web browser on HTTPS and viewing the certificate will show that the default certificate issued by dmgr.software.eng.us (the dmgr) and issued to was2.software.eng.us (the node server) is being used to secure the connection.

It is important to recognize that the default certificates in CellDefaultKeystore and NodeDefaultKeyStore are IBM self-signed certificate, meaning the certificate is not trusted by a certificate authority, thus the web browser will state that the site being requested is not safe.

Similarly, you could add your own self-signed certificate to the keystore and update the SSL configuration to use your own self-signed certificate as the default certificate and you will get the same prompt. In this example, I created a self-signed certificate for FreeKB in the keystore and updated the SSL configuration to use the FreeKB certificate as the default certificate.

The browser warning is perfectly OK when working in a development environment. However, when you are ready to publish your application to production, you certainly would not want your end users getting the message that your site is not safe. Thus begins the real journey here. Let's take a look at how you would add a certificate that is trusted by a certificate authority to WebSphere.

It is also important to recongize that if you start messing around with SSL configurations and have the following option selected, applications will start using the new SSL configurations in real time. Be careful here. You may want to disable this feature so that applications must be restarted to pick up changes made to the SSL configuration.