Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows
i5/OS: Tivoli Directory Server
This section describes procedures for configuring i5/OS Tivoli Directory Server over SSL:
Overview
You may want to configure WebSphere Application Server and WebSphere Portal Express access to your LDAP user registry over SSL to ensure the confidentiality of the data exchanged between WebSphere Application Server, WebSphere Portal Express, and your LDAP user registry. For example, user passwords are sent over the network between LDAP user registry and WebSphere Portal Express. This occurs to set the password if WebSphere Portal Express user management tools are used to create users and change passwords and also when WebSphere Application Server authenticates any user name and password pair through an LDAP BIND operation. Configuring LDAP over SSL may be important to protect sensitive data. Also, it may be required to ensure that user attributes that are retrieved from the directory are not viewed by someone watching packets on the network, if the attributes of a user include sensitive information or privacy is a concern.
In order to ensure that all this information remains private, it is necessary to configure both WebSphere Application Server and WebSphere Portal Express to use LDAP over SSL to the LDAP user registry. Configuring LDAP over SSL for WebSphere Application Server and WebSphere Portal Express is a separate operation from configuring the IBM HTTP Server to accept incoming browser requests over HTTPS, or configuring HTTPS between the IBM HTTP Server and WebSphere Application Server in a distributed setup.
A full primer on the configuration of all the LDAP user registries and WebSphere Application Server is beyond the scope of this portal Server documentation. Consult the documentation for your LDAP server to configure the directory for SSL traffic. For Tivoli Directory Server, see the most current documentation on IBM LDAP Implementation at http://www.ibm.com/software/webservers/appserv/was/support/. Refer to http://www.redbooks.ibm.com/ and do a search for Security Handbooks for the latest information about WebSphere Application Server security and LDAP over SSL. You may also consult the http://www.ibm.com/software/webservers/appserv/was/library/.
|
About keys and certificates
In general, the task of setting up WebSphere Application Server and WebSphere Portal Express to use LDAP over SSL to the LDAP user registry consists of bringing the necessary certificates into key storage files that WebSphere Application Server and WebSphere Portal Express will use. The necessary certificates mentioned are the signing certificates for the LDAP server certificate. The important point to note is that any certificates required to establish the full certificate signing trust chain must be made available to WebSphere Application Server and WebSphere Portal Express. For a self-signed certificate, the certificate trust chain consists of only the one self-signed LDAP server certificate. For a certificate signed by a CA, the certificate chain confirming the identity and validity of the signing CA must be included. Either a purchased certificate or a self-generated CA signing certificate may be used. Some configuration setting changes must also be made to tell WebSphere Application Server and WebSphere Portal Express that LDAP over SSL should be used. Usually, it is only necessary to bring a signing certificate from the LDAP server to the WebSphere Application Server and WebSphere Portal Express. This step allows the authentication of the server side of the SSL connection. WebSphere Application Server and WebSphere Portal Express are LDAP clients to the LDAP user registry server. The client side is authenticated by doing an LDAP BIND within the SSL connection. The identity used by WebSphere Application Server to perform this BIND is the Bind DN configured on the WebSphere Application Server Security Console.
In some cases, if the LDAP user registry is configured to require mutually authenticated SSL for the LDAP connection, meaning that it will request the client-side certificate, then signing certificates for WebSphere Application Server and WebSphere Portal Express must be moved to the LDAP Server key storage. In this case, WebSphere Application Server and WebSphere Portal Express will still do LDAP BINDs using the IDs and passwords configured, even though the SSL connection has already performed a mutual authentication.
Set up LDAP over SSL
IBM recommends that you first get LDAP (non-SSL) successfully working before setting up LDAP over SSL. This allows you to verify that the directory is responding to LDAP requests before setting it up for SSL.
1. Install WebSphere Portal Express and WebSphere Application Server
Refer to Installing on i5/OS for more information.
Also refer to Installing on i5/OS for instructions on how to install WebSphere Portal Express on an existing profile of WebSphere Application Server that has security enabled.
2. Install and setup your LDAP
IBM recommends that you first get LDAP (non-SSL) successfully working before setting up LDAP over SSL. This allows you to verify that the directory is responding to LDAP requests before setting it up for SSL. Refer to Tivoli Directory Server for more information.
3. Generate or import certificates as necessary and activate SSL on the directory
It is possible for Tivoli Directory Server to use either self-signed certificates or signing certificates signed by a CA (Certificate Authority) to enable LDAP over SSL.
Tivoli Directory Server includes a security key management utility, such as gsk6ikm, which can be used to generate a self-signed certificate or to import purchased certificates into the Tivoli Directory Server keystore. You should consult the Tivoli Directory Server documentation for the details of how to import a CA certificate or create a self-signed certificate in a key database file and extract that certificate so that it can be moved to the WebSphere Application Server and WebSphere Portal Express.
Optionally, you may use the System i5 Digital Certificate Manager. See the Digital Certificate Manager topic in the System i5 information center for more information.
A brief overview of the steps to create a self-signed certificate are below:
- Activate the security key management utility. For example, gsk6ikm.
- Open an existing CMS Key Database file, if your directory server is already configured for SSL, or create a new CMS Key Database file. If you open an existing file, provide the password for that file. If you create a new file, you are asked to supply a password to secure access to that file. You must remember that password.
- Within that CMS Key Database file, create a new self-signed certificate, using X.509 Version 3 format and 1024-bit key size. Give the certificate a label. You must remember this label.
- Extract the new self-signed certificate as a certificate file using Base64-encoded ASCII data as the data type. This will save the certificate to a filename of your choice with an extension of .arm.
- If it is not already configured, set up Tivoli Directory Server for LDAP over SSL using the CMS Key Database file containing the self-signed certificate. For details on this step, consult the Tivoli Directory Server documentation.
4. Import certificates to WebSphere Portal Express to enable SSL connection
Moving LDAP server certificates to WebSphere Application Server and WebSphere Portal Express
Make the signing certificate from Tivoli Directory Server (either the CA certificate or the self-signed certificate) available to the WebSphere Application Server and WebSphere Portal Express machine. This can be done by moving the file through a network transfer or removable media. Note that a CA certificate must be in Base64-encoded ASCII data format as a .arm file in order to be imported by the WebSphere Application Server key management utilities. The Tivoli Directory Server key management utilities (gsk6ikm) can be used to format a CA certificate which is not in the right format.
Importing certificates to a WebSphere Application Server keystore
If your application uses commercial certificate authority certificates (signer or CA certificates), you may be able to use the cacerts keystore (the default trust keystore) with your application. The integrated file system path for cacerts is /QIBM/ProdData/Java400/jdk14/lib/security/cacerts. However, in no case should you attempt to modify the original cacerts keystore. Create a private copy of the cacerts file and then add or remove certificates to the private copy. The password for cacerts is changeit. Be sure to change the password that protects your private copy of the cacerts file. Also, note that initially all keystores created using iKeyman contain a number of commercial CA certificates.
You can create your Java keystores in any System i5 integrated file system directory. However, it may be convenient to place them in the same directory as those that are used by your WebSphere Application Server profile. This may make it easier to include them in your backup and restore procedure. WebSphere Application Server provides an initial set of Java keystores that are used to secure connections between WebSphere components. These keystores are found in the etc directory of your WebSphere Application Server profile. For example, the keystores for the default profile are found in the app_server_root/default/etc directory.
For an example of how to create a Java keystore, see Using Java keystore files in the WebSphere Application Server for System i5 information center.
Importing certificates to a WebSphere Portal Express keystore
You must also import the certificates to a keystore that can be used by the WebSphere Portal Express. In this case, WebSphere Portal Express has no configuration setting to point to a specifically named Java Key Store file. Instead, import the certificates into the default keystore file of the JVM, cacerts. However, in no case should you attempt to modify the cacerts keystore. Rather, you should create a private copy of the cacerts file, and then add or remove certificates. The configured truststore in the SSL configuration of the CSIv2 Outbound Transport must also be updated.
5. Close down the non-SSL port of the LDAP user registry server (optional)
This is an optional step. Closing the non-SSL port of the directory will ensure that traffic exchanged with the directory by WebSphere Application Server, WebSphere Portal Express, or any other application, is confidential.
Parent topic:
Tivoli Directory Server