3 Configuring Business Services Server Security

This chapter contains the following topics:

Note:

This chapter covers the authentication of users of business services. For information about authorizing users to access published business service objects, see "Managing Published Business Services Security" in the JD Edwards EnterpriseOne Tools Security Administration Guide.

3.1 Understanding Business Services Server Security

JD Edwards EnterpriseOne provides authentication security to ensure that published business service users are authenticated in JD Edwards EnterpriseOne. The Business Services Server uses the JD Edwards EnterpriseOne Login Module as the authentication mechanism for authenticating users against the security server.

The module is automatically installed during the deployment of a JD Edwards EnterpriseOne business services package to the Business Services Server and configured for all published services. The module uses Java authentication and authorization service (JAAS) to validate the JD Edwards EnterpriseOne users against the JD Edwards EnterpriseOne Security Server.

To allow access to JD Edwards EnterpriseOne published business services without providing user credentials, you must set up anonymous login. Anonymous login directs the application server to use the anonymous login credentials stored in the jdbj.ini file for user authentication, instead of the EnterpriseOne Login Module.

See Also:

3.2 Securing WAS profiles (WebSphere application servers only)

As specifically directed by the IBM WebSphere administration documentation, you should ensure that your WebSphere installation meets these general recommendations:

  • Standalone configuration - Secure the default profile

  • Network Deployment configuration - Create a new profile and secure that profile

  • Recommended method of securing profile via WAS Integrated Solutions Console:

    • Administrative security: Enable Administrative security.

    • Application security: Enable application security.

    • Java 2 security: Disabled.

    • User account repositories: Federated repositories with the admin_user and admin_password (same as defined in soap.client.props file for profile).

3.3 Setting Up Anonymous Login

This section contains the following topics:

3.3.1 Understanding Anonymous Login

Anonymous login provides a mechanism to access published business services without providing JD Edwards EnterpriseOne user credentials. To enable anonymous login, you must disable the authentication mechanism (E1 Login Module) for a published business service in the application server. When the authentication mechanism is disabled, instead of using the user credentials of the consumer of the published business service for authentication, the application server uses the anonymous login credentials stored in the jdbj.ini file on the application server. These credentials are authenticated by the JD Edwards EnterpriseOne Security Server. The anonymous login password in the jdbj.ini file is encrypted.

You must configure anonymous login for each individual published business service by disabling the default authentication mechanism for that service. If the authentication mechanism is not disabled for a published business service, the user request will be rejected even if the anonymous login credentials have been entered in the jdbj.ini file.

You use Server Manager to enter these anonymous login credentials in the jdbj.ini configuration file:

  • Bootstrap User

  • Bootstrap User Password

  • Bootstrap Role

  • Bootstrap Environment

Note:

The anonymous login must be configured every time the Business Services Server is deployed.

See "JDBJ Bootstrap Session" in the Server Manager Guide for information on how to configure these settings.

3.3.2 Configuring WebSphere to Use Anonymous Login

In WebSphere, you can disable security for a published business service, which directs the system to use anonymous login credentials.

Note:

If you want to configure Anonymous login for a JAX-WS web service package on IBM WebSphere, see Configuring WebSphere to Use Anonymous Login.

This section provides an example of turning off the security for the CustomerManager reference implementation, which is a fully functional example of a published business service. Use it as an example to help you disable security for a particular published business service so that the system uses anonymous login instead.

To set up anonymous login on IBM WebSphere:

  1. Locate ibm-webservices-bnd.xmi and ibm-webservices-ext.xmi, which are in the following two locations:

    • WebSphere Home\AppServer\profiles\profile name\config\cells\Cell Name\applications\Application Name\deployments\Server\Web Module\WEB-INF

    • WebSphere Home\AppServer\profiles\profile name\installedApps\Cell Name\Application Name\Web Module Name\WEB-INF

  2. Make a backup of these two files in both locations.

  3. Using the following example of the RI_CustomerManager web service, delete the bold text from both the ibm-webservices-bnd.xmi and ibm-webservices-ext.xmi files. You must delete the code from these files in both locations where the files reside:

    • In the ibm-webservices-bnd.xmi file, delete the text shown in bold in this code sample:

       <wsdescBindings xmi:id="WSDescBinding_1185554582312" wsDescNameLink="RI_CustomerManager">
         <pcBindings xmi:id="PCBinding_1185554582312" pcNameLink="RI_CustomerManagerHttpPort" scope="Application">
           
           <securityRequestConsumerBindingConfig xmi:id="SecurityRequestConsumerBindingConfig_1185554610375910436757521891737910436757521891737">
             <tokenConsumer xmi:id="TokenConsumer_1185554610375910436757521891737" classname="com.ibm.wsspi.wssecurity.token.UsernameTokenConsumer" name="UserTokenConsumer">
               <valueType xmi:id="ValueType_1185554610375910436757521891737" localName="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken" name="Username Token"/>
               <jAASConfig xmi:id="JAASConfig_1186013028227" configName="e1BssvLogin"/>
               <partReference xmi:id="PartReference_1185554610375910436757521891737" part="UserToken"/>
             </tokenConsumer>
           </securityRequestConsumerBindingConfig>    
         
         </pcBindings>
       </wsdescBindings>
      
    • In the ibm-webservices-ext.xmi file, delete the text shown in bold in this code sample:

       <wsDescExt wsDescNameLink="RI_CustomerManager" xmi:id="WsDescExt_1185554582328">
         <pcBinding pcNameLink="RI_CustomerManagerHttpPort" xmi:id="PcBinding_1185554582328">
           
           <serverServiceConfig xmi:id="ServerServiceConfig_118555460310966390350416797703696639035041679770369">
             <securityRequestConsumerServiceConfig xmi:id="SecurityRequestConsumerBindingConfig_118555460310966390350416797703696639035041679770369">
               <caller name="basicAuth" part="" uri="" localName="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken"/><requiredSecurityToken xmi:id="RequiredSecurityToken_11855546031096639035041679770369" name="UserToken" uri="" localName="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken" usage="Required"/>
             </securityRequestConsumerServiceConfig>
           </serverServiceConfig>
         
         </pcBinding> 
       </wsDescExt>
      
  4. Restart the application server.

3.3.3 Configuring WebLogic to Use Anonymous Login

For a business services.ear that was built for the WebLogic Server (WLS) by running the Migration Utility or that was built directly by using JDeveloper 11g, you cannot enable anonymous login for published business services running on WLS 10.3.2 through the WLS administrative console.

With Tools Release 9.1 Update 3.1, if you are working on WLS 10.3.5 or later WLS version, you can use the WebLogic Server Admin Console to remove the security policy that is attached to a web service so that you can use Anonymous Login.

If you are using WLS 10.3.5 or later version, you must install the WebLogic service patch. For detail information about installing the service patch, see Bug 12761125.

Note:

If you have applied any other type of SSL certificate to WLS, this patch may not work. The workaround is to remove the certificate, then remove the WS-policy, and then apply the certificate again.

If you are running a WebLogic Server (version 10.3.5 or 10.3.6) on a Windows platform, you must remove the class path from the server before you remove the security policy, and then you must add the class path back to the server after you remove the security policy.

3.3.3.1 Removing the Class Path from a WebLogic Server Running on a Windows Platform

Note:

The steps in this task are required only if you are running a WebLogic Server 10.3.5 or later version on a Windows platform.

This task is not applicable if your WebLogic Server is running on a non-Windows platform.

Use these steps to remove and save the WebLogic server class path:

  1. Log into the WebLogic Admin Console.

  2. On the left side Domain Structure section, expand Environment, and then click the Server option.

  3. From the list of servers, click on the server where your business service package is deployed.

    The server does not need to be running at this time.

  4. On the right side Settings page, click the Configuration tab, and then click the Server Start tab.

  5. From the left side Change Center section, click the Lock & Edit button.

  6. On the right side Settings page, copy the entire entry from the Class Path section and paste the entry in Notepad and save it.

  7. On the Admin Console on the right side Settings page, delete the entry in the Class Path section.

  8. Click Save.

    A message stating that the settings were successfully updates appears on the Setting page.

  9. On the left side Change Center section, click Activate Changes.

  10. Find the server that you selected above and do one of the following:

    • If the managed server is in a stopped state, start it.

    • If the managed server is in a running state, then stop it and start it.

    Now you can remove the security policy for a web service.

    See Removing the Security Policy from an EnterpriseOne Web Service (Release 9.1 Update 3.1)

3.3.3.2 Adding the Class Path Back to the WebLogic Server (Windows Platform Only)

Note:

The steps in this task are required only if you are running a WebLogic Server 10.3.5 or later version on a Windows platform.

This task is not applicable if your WebLogic server is running on a non-Windows platform.

After you remove one or more security policies from your web services, you must add the class path back to your WebLogic Server so that web services that still have a security policy work.

Use the following steps to add the server class path back to the WebLogic Server:

  1. From the Change Center section on left side of the admin console, expand Environment, click the Server option, and select the same server you selected in the previous set of steps.

  2. On the right side Settings page, click the Configuration tab, and then click the Server Start tab.

  3. On left side Change Center section, click the Lock & Edit button.

  4. On the right side Settings page, copy and paste the class path entry that you saved in Notepad from the previous task to the Class Path section.

  5. Click Save.

  6. On the left side Change Center section, click the Activate Changes button.

  7. Restart the server.

Now, web services with security policy attached and web services without a security policy can be run on the Windows platform.

3.3.4 Removing the Security Policy from an EnterpriseOne Web Service (Release 9.1 Update 3.1)

If you are running WLS 10.3.5 or later, you can use the WebLogic Server Admin Console to remove the security policy that is attached to an EnterpriseOne web service so that you can use Anonymous Login.

Important:

If you are running WLS 11g on a Windows platform you must remove the class path from the WebLogic Server before you remove the security policy.

See Removing the Class Path from a WebLogic Server Running on a Windows Platform

If you are running WLS 12c on a Windows platform, you are not required to remove the server start class path. (Release 9.1 Update 4)

When you remove the HTTP security policy, the authentication uses the BootStrap User ID and Password in jdbj.ini for BSSV. You are not able to use WS-Security in the Soap Header section because Anonymous login is mandatory.

Every time you redeploy the business service package, you must manually detach the security policy file from the web services using the WebLogic Admin Console.

Note:

  • The policy file name for JAX-RPC is Wssp1.2-20077-Https-Usernametoken-Plain.xml.

  • The policy file name for JAX-WS is bssvpolicy.xml.

Use these steps to remove the security policy from an EnterpriseOne web service:

Important:

The deployment must be active.
  1. On the WebLogic Admin Console, go to Deployments and click the deployment that you want to modify.

    The list of services appears under the deployment that you selected.

  2. Click the service from which you want to remove the security policy.

  3. On the right side Settings page, click the Configuration tab, and then click the WS-Policy tab.

    The service endpoint and the policy attached to it appear on the Settings page.

  4. Click the service end point.

  5. From the left side Change Center section, click Lock & Edit.

    A list of policies appears in the Settings page.

  6. Under Chosen Endpoint Policies on the Settings page, select the security policy to be removed and use the arrow button to move the policy to the Available Endpoint Policies on the left side.

  7. Click OK.

    A message appears on the Settings page indicting that the deployment plan was successfully created and identifies the location of the deployment plan.

    The first time that you remove a policy, the Plan.xml file is created under these two locations:

    • -C:\jde_agent\SCFHA\targets\BSSV_WLS_7020\owl_deployment\E1Services-DV900-wls.ear\ app\Plan.xml

    • -C:\Oracle\Middleware\user_projects\domains\BSSVHTTP\servers\BSSV_HTTP_7080\stage\BSSV_HTTP_7080\plan\Plan.xml

  8. Repeat steps 2 through 7 to remove security policies from additional web services.

    After completing all of the policy removals, perform the next steps to update the deployment.

  9. On the WebLogic Admin Console, go to Deployments and select the deployment that you modified.

  10. Click Update.

  11. In the next screen, select the option, Update this application in place with new deployment plan changes.

    A deployment plan must be specified for this option.

  12. Click Next.

  13. Click Finish.

Now the web services from which you removed the policy can be invoked without passing the user name and password (anonymous access) in the SOAP header.

Important:

If you are running your WLS on a Windows platform you must add the class path back to the WebLogic Server before you run your web service.

See Adding the Class Path Back to the WebLogic Server (Windows Platform Only)

Note:

To reattach a policy to a web service, use the above steps, except in Step 6, move the security policy from the left side (Available Endpoint Polices) to the right side (Chosen Endpoint Policies).

3.4 Enabling SSL for Provider and Consumer Business Services

This section describes how to enable SSL for business services running on an IBM WebSphere Application Server (WAS) for both Provider and Consumer Scenarios. SSL is enabled for business services running on Oracle WebLogic Server by default. (Release 9.1 Update 4)

You can disable SSL for business services running on the Oracle WebLogic Server. See Removing the Security Policy from an EnterpriseOne Web Service (Release 9.1 Update 3.1)

3.4.1 Configuring SSL with IBM WebSphere Application Server (WAS)

The section describes how to configure Secure Socket Layer (SSL) with the IBM WebSphere Application Server and includes these tasks:

  • Configuring SSL on the IBM HTTP Server

  • Configuring SSL on IBM WebSphere

  • Configuring BSSV for SSL and WebSphere and Server Manager

3.4.1.1 Configuring SSL on the IBM HTTP Server

For production environments, we recommend you request a Self-Signed Certificate from a Certificate Authority. For instructions to request a CA-Signed Personal Certificate, refer to the IBM Info Center. The procedure in this section assume you have already obtained the CA-Signed Personal Certificate.

To configure SSL on the IBM HTTP Server:

  1. Start the Key Management Utility by navigating the following path:

    Start > Programs > IBM HTTP Server V 6.1 > Start Key Management Utility

  2. Create a folder named keys in the HTTP Server directory.

  3. Start the ikeyMan utility which is located in your HTTP Server's bin directory (for Windows platforms, this path is typically:

    C:/WebSphere/IBM HTTP Server/bin

  4. In the ikeyMan utility, create a Key Database File by selecting:

    Key Database File > New

  5. At the prompt, complete these fields:

    Field Values
    Key Database Type CMS

    Note that only CMS is supported with the IBM HTTP Server.

    File Name serverkey.kdb
    Location C:\WebSphere\IBM HTTP Server\keys

  6. Enter the password (for example, serverkey) and select this option:

    stash the password file

  7. Click the OK button.

  8. From the drop down box, select this option:

    Personal Certificates

  9. Click the New Self-Signed button.

  10. On the next screen complete these fields:

    Field Values
    Key Label Enter any label. For example:
    • server_cert

    Version X509V3
    Key Size 1024
    Common Name Enter a fully qualified server name. For example:
    • denicdep5.mlab.jdedwards.com

    Organization Enter your organization name. For example:
    • Oracle

    Country or region Enter your country or region. For example:
    • US

    Validity Period Enter the validity for your certificate. For example:
    • 365 days


  11. Click the OK button.

    The program displays your certificate in the list.

  12. Delete all other certificates that might exist.

  13. Open the httpd.conf file in a text editor, and add the following virtual host definition.

    Note:

    The text in the httpd.conf file is case sensitive; type the host definition exactly as shown.

    If you have already configured a port on the HTTP Server (for example, port 85), the file will include an Alias. You should use the same alias under your Virtual Host definition as shown by the bold segment in the section file sample below.

    LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
    <IfModule mod_ibm_ssl.c>
    Listen 443
    <VirtualHost denicdep5.mlab.jdedwards.com:443>
    Alias /jde "C:/WebSphere/AppServer/installedApps
    /denicdep5Node01/EA_JS_85.ear/webclient.war"
    SSLEnable
    </VirtualHost>
    </IfModule>
    SSLDisable
    KeyFile "C:/WebSphere/IBMIHS/keys/serverkey.kdb"
    

    For BSSV, the following Virtual Host definition should be used.

    Listen 0.0.0.0:443
    ## IPv6 support:
    <VirtualHost *:443>
    Alias /PD812_WEB "C:\WebSphere61\AppServer\profiles\BSSV/installedApps/[node_name]/BSSV_PD_93.ear\PD812_WEB.war"
    SSLEnable
    </VirtualHost>
    <Directory "C:\WebSphere61\AppServer\profiles\BSSV/installedApps/[node_name]/BSSV_PD_93.ear\PD812_WEB.war\WEB_INF">
    Order Deny,Allow
    Deny from All
    </Directory>
    <Directory "C:\WebSphere61\AppServer\profiles\BSSV/installedApps/[node_name]/BSSV_PD_93.ear\PD812_WEB.war">
    Order Deny,Allow
    Allow from All
    </Directory>
    </IfModule>
    KeyFile C:\WebSphere61\IHS2\keys\serverkey.kdb
    SSLDisable
    # End of example SSL configuration
    

3.4.1.2 Configuring SSL on IBM WebSphere

To configure SSL on the IBM HTTP Server:

  1. Log on to your WebSphere Admin Console.

  2. Navigate to Environment > Virtual Hosts.

  3. Select your virtual host.

    For example, if you initially installed your application on port 85, then the virtual host should have a name similar to VH_EA_JS_85.

  4. Under the virtual host, select Additional Properties > Host Aliases.

  5. Under Host Aliases, click the New button.

  6. Create a new host alias by completing these fields:

    Field Values
    Host Enter a fully qualified server name. For example:
    • denicdep5.mlab.jdedwards.com

    Port Enter the default SSL port number, which is:
    • 443


  7. Regenerate the plugin and restart your Application Server.

  8. Restart the HTTP Server.

    At this point you should be able to login to the WebSphere Application Server using the following URL:

    https://fully_qualified_server_name/jde/E1Menu.maf

3.4.1.3 Configuring BSSV for SSL and WebSphere and Server Manager

This section describes the additional steps that are required in order for BSSV to work with SSL and WebSphere and the Server Manager for JD Edwards EnterpriseOne.

  1. From the WAS Admin Console, extract the signer and personal certificates from the node default trust store and node default key store.

  2. Using the ikeyman tool, open the dummy client key file (DummyClientKeyFile.jks) and import the personal signer certificate that you extracted in Step 1 of this procedure.

  3. Open the dummy client trust file (DummyClientTrustFile.jks) and import the signer certificate that you extracted in Step 1 of this procedure.

  4. Using the ikeyman tool, open the plugin-key.kdb of the HTTP Server that is configured with the WAS Profile hosting the BSSV Server.

  5. Import the personal signer and signer certificates extracted in Step 1 of this procedure into the plugin-key.kdb file.

  6. Modify the httpd.conf file and change the key store value as shown below:

    keystore=plugin-key.kdb

  7. If you want to disable HTTP access and only have HTTPS (SSL) access, you must comment the include file for BSSV that was automatically added by Server Manager. The name of the Server Manage configuration file is scf_xxxx.conf.

  8. After completing these steps and restarting HTTP server, the secure https url should be working properly.

3.5 Enabling SSL for HTTP Request/Reply

In JD Edwards EnterpriseOne, you can configure a business service to communicate with a third-party system using HTTP POST. You can secure communication between the Business Services Server and third-party sites by using the Secure Sockets Layer (SSL) protocol.

This section describes:

3.5.1 INI Configuration Changes for Communication Over SSL

The KEYSTORE and TRUST_STORE sections of the jdeinterop.ini file contain parameters that you must complete to enable SSL for HTTP Request/Reply. When you create a certificate for communication over SSL, the values that you enter for the certificate should match the values set for these parameters.

The following parameters in the KEYSTORE section of the jdeinterop.ini are used for the SSL configuration for HTTP Request/Reply:

Parameter Description
keystorefile= The path to the keystore file.
keystorepasswd= The keystore password.
keyalias= The keystore alias name.
certificatepasswd= The keystore certificate password.

Note:

The default settings for these parameters are blank.

The following parameters in the TRUST_STORE section of the jdeinterop.ini are used for the SSL configuration for HTTP Request/Reply:

Parameter Description
truststorefile= The path to the truststore file.
truststorepasswd= The truststore password.

Note:

The default settings for these parameters are blank.

3.5.2 Configuring Production Application Server to Work with Certificates

This section describes how to:

3.5.2.1 Configuring the HTTP Adapter Service

Perform these tasks to configure the HTTP Adapter Service:

  • Configure client authentication.

  • Check the trustability of the server during handshake.

To configure client authentication:

Create a certificate request (CSR) using keytool.

  1. Go to the HTTP Adapter deployed location.

    ../WEB-INF/classes/.

  2. From a command prompt navigate to:

    <Business Services deployed location>/WEB-INF/classes/.

  3. Use the following commands to create a certificate request:

    <JAVA_HOME>\bin\keytool -genkey -keyalg RSA -alias httpclientcer -keystore HTTPAdapterKS.keystore -keypass httpadapter -storepass httpadapter -dname "CN=Oracle,OU=Oracle,O=Oracle USA L=Redwood Shores,S=CA,C=US"

    Provide all the details for generating the key.

    <JAVA_HOME>\bin\keytool -certreq -alias httpclientcer -file clientkeyCSR -keystore HTTAdapterKS.kestore -keypass httpadapter -storepass httpadapter

    The preceding command generates the certificate request and writes to a file clientkeyCSR.

  4. You obtain the user certificate from a certification authority by submitting the generated CSR and saving it to a file HTTPAdapter.cer.

  5. Obtain the certification authority root certificate (rootCA.cer) and intermediate CA certificate (rootInterCA.cer).

  6. Import the signer certificates rootCA.cer and rootInterCA.cer in to HTTP Adapter's keystore using this command:

    <JAVA_HOME>\bin\keytool -import -alias rootCAcer -file rootCA.cer -keystore HTTAdapterKS.keystore -keypass httpadapter -storepass httpadapter

    <JAVA_HOME>\bin\keytool -import -alias rootInterCAcer -file rootInterCA.cer -keystore HTTAdapterKS.keystore -keypass httpadapter -storepass httpadapter

  7. Import the certificate HTTPAdapter.cer in to the HTTP Adapter's key store using the following command:

    <JAVA_HOME>\bin\keytool -import -v -alias AliasName -file HTTPAdapter.cer -keystore HTTAdapterKS.keystore -keypass KeyPassword -storepass httpadapter

    Where AliasName is the alias of the certificate. This value must be updated in the jdeinterop.ini file for keyalias parameter after the certificate is imported.

    Where KeyPassword is the password for the certificate stored in the keystore. This value must be updated in the jdeinterop.ini file for property certficatepasswd after the certificate is imported

To check the trustability of the server during handshake:

Obtain the SSL certificate (ServerRoot.cer) of server's certificate root CA.

  1. Go to the HTTP Adapter deployed location.

    ../WEB-INF/classes/.

  2. From a command prompt navigate to:

    <Business Services deployed location>/WEB-INF/classes/

  3. Import the certificate ServerRoot.cer in to the HTTP Adapter's trust store using the following command:

    <JAVA_HOME>\bin\keytool -import -v -trustcacerts -alias AliasName -file ServerRoot.cer -keystore cacerts -keypass KeyPassword -storepass changeit

    where AliasName is the name for alias of the certificate.

    where KeyPassword is the password for the certificate stored in the keystore.

3.5.2.2 Configuring the Listener Service

Perform these tasks to configure the listener service:

  • Configure SSL for the Listener Service on a IBM HTTP Server.

To configure SSL for the listener service on an IBM HTTP Server:

  1. Open IKeyman tool (ikeyman.bat under:<IBM_HTTP_SERVER_INSTALL_ROOT>\bin).

    Description of image028.gif follows
    Description of the illustration image028.gif

  2. On the New screen, select CMS from the Key database type list and complete these fields to create a new key database file:

    • File name

      Enter a name or click the Browse button to select a key database file.

    • Location

      Enter the path to the key database file.

  3. Click OK.

    The Password Prompt window opens.

  4. On Password Prompt, enter a password in the Password and Confirm Password fields, and then select the "Stash password to a file?" option.

    Description of image030.gif follows
    Description of the illustration image030.gif

  5. On Create New Key and Certificate Request, enter the name of the new certificate in the Common Name field. Enter the name of the file where the certificate request is stored, and click OK.

  6. Select Personal certificate requests from Key database context menu and click New.

    Description of image031.gif follows
    Description of the illustration image031.gif

  7. Provide the required information. The Certificate Request File is created at <IBM_HTTP_SERVER_INSTALL_ROOT>\bin. By default it is certreq.arm.

  8. Create a CSR at any Certificate Authority with the Certificate Request information contained in the Certificate Request File.

    Also, obtain Root CA and Intermediate CA certificate from the Certificate Authority vendor.

  9. Select the Signer Certificates option from Key database content.

    Description of image032.gif follows
    Description of the illustration image032.gif

  10. Add the Root CA and then Intermediate CA by clicking Add.

    Description of image033.gif follows
    Description of the illustration image033.gif

  11. Select the Personal Certificates option from Key database content. Add the certificate provided by CA by clicking the Receive option.

  12. Save the file. A key database file with extension.kdb is created.

  13. Go to the file <IBM_HTTP_SERVER_INSTALL_ROOT>\conf\httpd.conf and add the following to the VirtualHost:

    LoadModule  ibm_ssl_module   modules/mod_ibm_ssl.so 
    Listen 443
    <VirtualHost  DENOSCL244.mlab.jdedwards.com:443>
    SSLEnable
    SSLClientAuth none
    </VirtualHost>  
    SSLDisable
    Keyfile "C:\Program Files\IBM\IBM HTTP Server\bin\key.kdb"
    

    Customize it according to your environment.

    DENOSCL244.mlab.jdedwards.com -  DNS Name
    Keyfile "C:\Program Files\IBM\IBM HTTP Server\bin\key.kdb" -Key Database
    
  14. Go to plugin-cfg.xml under <WAS_INSTALL_ROOT>/Plugin/config/webserver1, where webserver1 is the webserver name.

    Add <Uri Name="/ListenerService/ ListenerService"/> under the node UriGroup.

    Add <VirtualHost Name="*:443"/> under node VirtualHostGroup

  15. Go to plugin-cfg.xml under<WAS_INSTALL_ROOT>/profiles/default/cells/DENOSCL244Node01Cell/node/webserver1_node/servers/webserver1.

    Add <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/ListenerService/ListenerService"/> under the node UriGroup.

    Add <VirtualHost Name="*:443"/> under node VirtualHostGroup

  16. Restart WAS.

  17. Restart IBM HTTP Server.

  18. Deploy the Listener service.