Configure SSL between the IBM HTTP Server Administration Server and the deployment manager

Configure Secure Sockets Layer (SSL) between the deployment manager for WebSphere^® Application Server and the IBM^® HTTP Server administration server, which is called adminctl.

About this task

Version 6.1 of Application Server has new SSL management functions that need to be managed properly in order for IBM HTTP Server to connect with an SSL request. In earlier releases, SSL connections used default dummy certificates that were exchanged between IBM HTTP Server and the Application Server. In WebSphere Application Server Version 6.1, you must configure the Application Server to accept a self-signed certificate from IBM HTTP Server so SSL connections are accepted and transactions are completed.

If the Application Server and the IBM HTTP Server administration server are not configured correctly, the Application Server shows any errors that are received in the log file for the deployment manager. In situations where the IBM HTTP Server administration server is attempting to connect through SSL and the Application Server is not configured, you might receive an error that is similar to the following message:

-CWPKI0022E: SSL HANDSHAKE FAILURE:  A signer with
SubjectDN "CN=localhost" was sent from target host:port "null:null".
The signer may need to be added to local trust store "c:/619/app2/profiles/Dmgr01/config/cells/rjrCell02/trust.p12" 
located in SSL configuration alias "CellDefaultSSLSettings"
 loaded from SSL configuration file "security.xml".  
The extended error message from the SSL handshake
 exception is: "No trusted certificate found".

-IOException javax.net.ssl.SSLHandshakeException: 
com.ibm.jsse2.util.h: No trusted certificate found

Procedure

1. Obtain a self-signed server certificate. You can generate a new self-signed certificate or use the existing certificate from the IBM HTTP Server Web server plugin.
   • Use the existing self-signed certificate from the IBM HTTP Server Web server plugin.
   • Create a CMS key database file and a self-signed server certificate. Use the iKeyman utility for distributed operating systems and the gskkyman tool for z/OS^® operating systems. This step and later steps will assume that you are using the iKeyman utility.
     • Use the IBM HTTP Server iKeyman utility graphical user interface or command line to create a CMS key database file and a self-signed server certificate.
       Use the iKeyman utility to create a self-signed certificate for the IBM HTTP Server Administration Server and save the certificate as /conf/admin.kdb.
       

       Best practice: Make note of the password and select Stash password to a file.bprac

       The following fields are required for the certificate:
       

       Label

       adminselfSigned

       Common Name

       fully_qualified_host_name

2. IBM HTTP Server uses the z/OS gskkyman tool for key management to create a CMS key database file, public and private key pairs, and self-signed certificates. Alternatively, you can create a SAF keyring in place of a CMS key database file.
   • For information on gskkyman, see Key management using the native z/OS key database.
   • For information on creating SAF keyrings, see Authenticating with SAF on IBM HTTP Server and SSL keyfile directive.
3. Extract the self-signed certificate to a file using iKeyman utility.
   1. Select the certificate that you created in Step 1. For example, adminselfSigned.
   2. Click Extract Certificate. The recommended file name for extraction is C:\Program Files\IBM\HTTPServer\conf\cert.arm.
      Avoid trouble: Do not change the data type.gotcha
4. Modify the Administration Server configuration File, which is named admin.conf.
   1. Configure the file to load the IBM SSL module. Uncomment the following line:

      LoadModule ibm_ssl_module     modules/mod_ibm_ssl.so

   2. Enable SSL and define a key file to use. Uncomment the following lines to enable SSL and define a key file to use:

      SSLEnable
      SSLServerCert default
      Keyfile "C:/Program Files/IBM/HTTPServer5/conf/admin.kdb"

      Avoid trouble: Be aware of the following:
      

      • The key file directive must match the name and location of a valid key file that is installed on your system.
      • You must have IBM SSL support installed for this to work.
      • The "default" in SSLServerCert is the label, or name, of the self-signed certificate that is created when the plugin-key.kdb file was created.
      • The previous example uses SSLServerCert because the default self-signed certificate in the plugin-key.kdb is not flagged as the default certificate.

      gotcha
5. Start the administration server for IBM HTTP Server. Verify that the log file does not contain GSKIT errors.
6. Configure WebSphere Application Server.
   1. Log into the Administrative Console for the Application Server and start the deployment manager.
   2. Select Security > SSL certificate and key management.
   3. Select Manage endpoint security configurations. You are directed to a list of inbound and outbound endpoints.
   4. Select the outbound cell (cellDefaultSSLSettings,null). Select outbound cells because, in this setup, the Administration Console for the Application Server is the client, and the IBM HTTP Server Administration Server is the server.
      Avoid trouble: This setup is the opposite configuration from an SSL setup with the IBM HTTP Server plugin and the Application Server.gotcha
   5. In the Related Items section, click Key stores and certificates.
   6. Click CellDefaultTrustStore.
   7. In the Additional Properties section, click Signer Certificates.
   8. FTP the certificate file to the Application Server. Do not change the data type.
   9. In the collection panel for Signer Certificates, click Add. Enter the following information in the fields.

      Table 1. Signer Certificate information

      Name	Value
      Alias	adminselfSigned
      File name	file_name For example, enter the following: c:\program files\ibm\httpserver\conf\cert.arm

   10. Save the configuration changes to the administrative console.
   11. Stop the deployment manager.
   12. Start the deployment manager.