Setting up LDAP over SSL with Domino Directory


 

Overview

You might wish to configure WAS and WebSphere Portal access to the LDAP directory over SSL to ensure the confidentiality of the data exchanged between WAS, WebSphere Portal, and Domino Directory. For example, user passwords are sent over the network between the LDAP directory and WebSphere Portal. This occurs to set the password if WebSphere Portal user management tools are used to create users and change passwords and also when WAS authenticates any user name and password pair through an LDAP BIND operation. Configuring LDAP over SSL can be important to protect sensitive data. Also, it might be desirable 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.

To ensure that all this information remains private, configure both WAS and WebSphere Portal to use LDAP over SSL to the LDAP directory. Configuring LDAP over SSL for WAS and WebSphere Portal is a separate operation from configuring the HTTP Server to accept incoming browser requests over HTTPS, or configuring HTTPS between the HTTP Server and WAS in a distributed setup.

A full primer on the configuration of all the LDAP directories and WAS is beyond the scope of this WebSphere Portal documentation. Consult the documentation for the LDAP server to configure the directory for SSL traffic. For WAS, the IBM Redbook IBM WebSphere V5.0 Security, SG24-6573-00 is available, and Appendix B contains instructions for configuring WAS for LDAP over SSL. You can also consult the WAS product documentation.

It is recommended that you first get LDAP (nonSSL) 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.

 

About keys and certificates

Configure LDAP over SSL from WAS and WebSphere Portal to Domino as the LDAP directory is almost the same as for IBM Directory Server or any of the other LDAP directory servers. Domino will present a signed certificate as part of the LDAP-over-SSL handshake. The signer certificates for this Domino Directory server certificate must be available to WAS and WebSphere Portal. If the Domino Directory server certificate is self-signed, then that same self-signed certificate must be imported as a signer certificate into the named WAS Java Key Store (.jks) for WAS LDAP over SSL and into the cacerts file for WebSphere Portal usage. If the Domino Directory server certificate is signed by a CA certificate chain, then that CA certificate chain must be imported as signer certificates into the named WAS Java Key Store (.jks) for WAS LDAP over SSL and into the cacert s file for WebSphere Portal usage. The WAS and WebSphere Portal configuration steps are then identical to that for any other directory.

However, there are some slight differences in the Domino key management utilities; they generate key files that are compatible with the GSKIT key management tool, provided with IBM HTTP Server, but not directly with the WAS key management tool. So, if Domino key management has been used to generate self-signed certificates, then the GSKIT key management tool must be used as an intermediate step to extract that certificate in Base64-encoded ASCII format (the .arm file) which can then be imported to WAS and the default JSSE key stores using the WAS key management tool. To import the file, follow the procedures outlined here.

In general, the task of setting up WAS and WebSphere Portal to use LDAP over SSL to the LDAP directory consists of bringing the necessary certificates into key storage files that WAS and WebSphere Portal will use. The necessary certificates mentioned are the signing certificates for the LDAP server certificate. Some configuration setting changes must also be made to tell WAS and WebSphere Portal that LDAP over SSL should be used. Usually, you only need to bring a signing certificate from the LDAP server to WAS and WebSphere Portal. This step allows the authentication of the server side of the SSL connection. WAS and WebSphere Portal are LDAP clients to the LDAP directory server. The client side is authenticated by doing an LDAP BIND within the SSL connection. The identity used by WAS to perform this BIND is the Bind DN configured on the WAS Security Console. The identity used by WebSphere Portal to perform this BIND is the adminId.

In some cases, if the LDAP directory is configured to require mutually authenticated SSL for the LDAP connection, meaning that it will request the client-side certificate, then signing certificates for WAS and WebSphere Portal must be moved to the LDAP Server key storage. The mechanisms for importing these certificates on the various LDAP servers are vendor-specific. Consult the directory documentation for specific instructions. Even in this case, WAS and WebSphere Portal 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

It is required 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. Use the IBM Web Administration for iSeries tool for all of the WebSphere Portal configuration tasks. The wizard will create the necessary servers (HTTP and WAS), configures the server for Portal, configures the database for Portal, and configures the Portal server for security (LDAP).

  1. Install WebSphere Portal and WAS

  2. Install and set up the LDAP

  3. Generate or import certificates as necessary and activate SSL on the directory

  4. Import certificates to cacerts to enable SSL connection

  5. Close down the nonSSL port of the LDAP directory server (optional)

 

1. Install WebSphere Portal and WAS

Refer to Install WebSphere Portal for more information.

Also refer to Install WebSphere Portal for instructions on how to install WebSphere Portal on an existing instance of WAS that has security enabled.

 

2. Install and set up the LDAP

It is recommended 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. Use the IBM Web Administration for iSeries tool for all of the WebSphere Portal configuration tasks. The wizard will create the necessary servers (HTTP and WAS), configures the server for Portal, configures the database for Portal, and configures the Portal server for security (LDAP).

 

3. Generate or import certificates as necessary and activate SSL on the directory

It is possible for IBM Directory Server to use either self-signed certificates or signing certificates signed by a CA (Certificate Authority) to enable LDAP over SSL.

IBM 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 IBM Directory Server keystore. You should consult the IBM 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 WAS and WebSphere Portal.

Optionally, you can use the iSeries Digital Certificate Manager. See the Digital Certificate Manager topic in the iSeries Information Center for more information.

A brief overview of the steps to create a self-signed certificate are below:

  1. Activate the security key management utility. For example, gsk6ikm.

  2. Open an existing CMS Key Database file, if the 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.

  3. 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.

  4. 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 the choice with an extension of .arm.

  5. If it is not already configured, set up IBM Directory Server for LDAP over SSL using the CMS Key Database file containing the self-signed certificate. For details on this step, consult the IBM Directory Server documentation.

 

4. Import certificates to WebSphere Portal to enable SSL connection

 

Moving LDAP server certificates to WAS and WebSphere Portal

Make the signing certificate from Domino Directory (either the CA certificate or the self-signed certificate) available to the WAS and WebSphere Portal machine. You can do this 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 WAS key management utilities. The IBM HTTP Server key management utilities (IKeyMan) can be used to format a CA certificate that is not in the right format.

 

Importing certificates to a WAS keystore

If the application uses commercial certificate authority certificates (signer or CA certificates), you might be able to use the cacerts keystore (the default trust keystore) with the application. The integrated file system path for cacerts is /QIBM/ProdData/Java400/jdk13/lib/security/cacerts. However, in no case should you attempt to modify the cacerts keystore. Rather, create a private copy of the cacerts file, and then add or remove certificates. 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 the Java keystores in any iSeries integrated file system directory. However, it might be convenient to place them in the same directory as those that are used by the WebSphere instance. This might make it easier to include them in your backup and restore procedure. WAS 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 the WebSphere instance. For example, the keystores for the default instance are found in the /QIBM/UserData/WebAS5/Base/default/etc directory.

For an example of how to create a Java keystore, see Use Java keystore files in the WAS for iSeries Information Center.

 

Importing certificates to a WebSphere Portal keystore

You must also import the certificates to a keystore that can be used by the WebSphere Portal. In this case, WebSphere Portal 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, 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.

For more information about this topic, refer to the latest version of the WebSphere Portal Information Center at http://www.ibm.com/websphere/portal/library.

 

5. Close down the nonSSL port of the LDAP directory server (optional)

This is an optional step. Closing the nonSSL port of the directory will ensure that traffic exchanged with the directory by WAS, WebSphere Portal, or any other application, is confidential.

You must perform several additional configuration steps to enable SSL for uses other than LDAP, if WebSphere Portal components related to Collaborative Components are used.

For information about this topic, refer to the latest version of the WebSphere Portal Information Center at http://www.ibm.com/websphere/portal/library.

 

Next steps

You have completed this step. Continue to the next step by choosing one of the following topics:

 

See also