The following example illustrates how to use WebSphere® V6.1
or V7.0 to create and use your own SSL-enabled port. Before WebSphere Application Server V6.1 was released,
certificates were managed through the use of an external tool called
iKeyman. As of WebSphere Application Server V6.1, you
can use the Administrative Console to manage both certificates and
keys. Although you can use WebSphere V6.0 with SSL to
run Rich UI applications, the instructions for doing so are not included
here. The differences between V6.1 and V7.0 are described below.
For instructions on how to install and configure SSL for Tomcat,
see Apache Tomcat documentation.
Create an SSL-enabled port
To create a sample
SSL-enabled port, take the following steps. For more details, see
your WebSphere Application Server documentation.
Changing your key store and trust store passwords
In the following procedure, you create a new self-signed
certificate in your WebSphere Application Server
default key store and import the certificate into your default trust
store. Before you use the default key and trust stores, change their
passwords from the defaults to another value to create a more secure
environment. To change your key store and trust store passwords:
- Start your WebSphere V6.1 or V7.0 server
- Right click on the server and click Administration.
- Click Run administrative console.
- Log in to the Administrative Console.
- Expand Security and click SSL certificate and key management.
- Under Related Items, click Key stores and certificates.
- For WebSphere V6.1, click NodeDefaultKeyStore.
- For WebSphere V7.0, click NodeDefaultKeyStore.
Click Change password.
- Type your new password into the Change password and Confirm password
fields.
- Click OK.
- Repeat this process for NodeDefaultTrustStore.
Creating a personal certificate
A self-signed
certificate is useful when you are testing or when your Web site is
behind a firewall. Otherwise, obtain a certificate from a Certificate
Authority. To create a personal certificate:
- From your list of key stores and trust stores, click NodeDefaultKeyStore.
- Under Additional Properties, click Personal certificates.
- For WebSphere V6.1, click Create
a self-signed certificate.
- For WebSphere V7.0, click .
- Type the following values for the certificate:
- Alias
- SampleCert
- Common name
- Sample Server
- Organization
- IBM®
- Click OK.
In the list of certificates, you should now see samplecert.
Creating an SSL configuration
WebSphere Application Server uses SSL configurations
for SSL-based transports. To create an SSL configuration:
- From the left-hand pane, expand Security and click SSL
certificates and key management.
- Under Related Items, click SSL configurations.
- Click New.
- Type the following values:
- Name
- SampleConfig
- Trust store name
- NodeDefaultTrustStore
- Keystore name
- NodeDefaultKeyStore
- Click Get certificate aliases.
- Ensure that samplecert is selected as the Default server certificate
alias and the Default client certificate alias.
Click OK, and click Save.
In the list of SSL configurations, you should see SampleConfig.
Creating a Web container transport chain
Create
a Web container transport chain to use the SSL configuration that
you created:
- For WebSphere V6.1, from the left-hand pane,
expand Servers and click Application servers.
- For WebSphere V7.0, from the left-hand pane,
expand Servers and Server Types. Click WebSphere application
servers.
- Click server1 or your server name.
- Under Container Settings, expand Web Container Settings and click Web
container transport chains.
- Click New.
- In the Transport chain name field, type SampleInboundSecure.
- To select the Transport chain template, from the drop-down list,
click WebContainer-Secure(templates/chains | webcontainer-chains.xml#Chain_2).
- Click Next.
- In the Select a port page, type the following values:
- Port
- SamplePort
- Host
- *
- Port number
- 9444
If port 9444 is already in use, pick another port number
and use that number for the rest of the exercise.
- Click Next.
- Click .
SampleInboundSecure is now listed as a Web container
transport chain. Associate the sample SSL configuration with this
transport chain:
- Click SampleInboundSecure.
- Click SSL inbound channel.
- Under SSL Configuration, from the Select SSL Configuration drop-down
list, select SampleConfig .
- Click .
Adding the SSL-enabled port to the virtual host
Add
port 9444 to the virtual host:
- In the left-hand pane, expand Environment and click Virtual
Hosts .
- Click default_host.
- Under Additional Properties, click Host Aliases.
- On the Host Aliases page, click New.
- Keep * as the host name. Change the port to 9444.
- . In the list of ports, you should see 9444.
Stop and restart the server. Port 9444 is now an SSL-enabled
port.
Using the new SSL-enabled port to run a sample
To
use your port, start a WebSphere V6.1 or V7.0 server.
On your WebSphere server, install the EAR that
contains your deployed Rich UI application. To request an HTML file
such as RSSReader.html in the RSSReaderSample context, take one of
the following steps:
- Open a browser such as Internet Explorer, Safari®, or Mozilla
Firefox. Enter a URL in your browser using the newly-enabled SSL port:
https://localhost:9444/RSSReaderSample/RSSReader.html
- In your Project Explorer, right-click on an HTML file of an application
that has been published to WebSphere. Click Run
As, then click Run on Server.
If you are using a self-signed certificate, you might
see a "Security Alert", "Website Certified by an Unknown Authority",
or another warning, depending upon the browser. This warning indicates
that the certificate was signed by an unknown certifying authority.
Click the "View Certificate" or "Examine Certificate" button to verify
if the certificate is correct. If so, continue.
If the Common
Name on the certificate does not match the domain name in the requested
URL (localhost, in this case), you might also see a "Security Error:
Domain Name Mismatch" error. To verify the certificate, click the
View Certificate button, and continue as appropriate. To prevent
"man-in-the-middle" attacks, where a rogue program intercepts all
communication between a client and server, the client must verify
the server domain name that is specified in the certificate.