Managing Servers › How to Configure SSL Authentication

How to Configure SSL Authentication

As a system administrator, you can configure the web director to direct login requests to a specific web engine using the Secure Socket Layer (SSL) protocol. Configuring the SSL authentication provides enhanced login security while allowing users to access a higher performance connection.

More Information:

Set the Web Engine Capability by Web Director Parameters

Set Up SSL Login Environment

Choose the SSL Login Environment

Verify the Prerequisites

Verify the Prerequisites

Verify the following prerequisites before you begin the SSL configuration:

• Installed and configured CA SDM on the server where you want to implement SSL.
• Configured and assigned at least two web engines configured and assigned to a web director. For more information about how to configure web engines and web directors, see the How to Configure Server Process for CA SDM to Improve Performance scenario.

Set the Web Engine Capability by Web Director Parameters

After you configure the web engine to use a web director, the web engine can handle the web client requests. The web engine can service login requests (redirect nonlogins elsewhere) or nonlogin requests (redirect logins elsewhere) or both (‘general purpose’ web engine). The WebDirector parameter found in the <Host_Name>-web[#].cfg file determines how webengine can service login requests.

The following table shows the relationship between the web engine role and web director parameter setting:

Choose the SSL Login Environment

You can use the web director for a targeted SSL login in a mixed SSL/non-SSL web environment to redirect every web-login request to the specific SSL web engines. All other requests can be redirected to and serviced by the non-SSL web engines.

Choose from the following SSL Login environment:

• Non-SSL environment with basic load balancing
• Global SSL environment with Basic load balancing
• Targeted login in a non-SSL environment with optional load balancing
• Targeted SSL login in a mixed environment with optional load balancing

Non-SSL Environment with Basic Load-Balancing

You can use web director in a non-SSL environment with basic load-balancing. Web director balances load across all web engines according to each web engine willingness value. Each web engine can service login requests and nonlogin requests. The HTTP protocol is used for communication between the web client and the web server.

For each web engine under web director control, set the web director parameters in the web engine ‘<Host_Name>-web[#].cfg’ as follows:

• UseDirector: Yes
• WebDirectorSlumpName: (do not change this value)
• WillingnessValue: [1 through 10]
• RedirectingURL: (the preappended protocol value can be either missing or ‘http’)

Global SSL Environment with Basic Load-Balancing

You can use web director in a global SSL environment with basic load-balancing. Web director balances load across all web engines according to each web engine willingness value. Each web engine can service login and nonlogin requests. The HTTPS protocol must be used for all communications between web clients and the web server.

For each web engine under web director control, set the web director parameters in the web engine ‘<Host_Name>-web[#].cfg’ as follows:

• UseDirector: Yes
• WebDirectorSlumpName: (do not change this value)
• WillingnessValue: [1 through 10]
• RedirectingURL: (the preappended protocol value must be ‘https’)

Targeted Login in a Non-SSL Environment with Optional Load-Balancing

You can use web director for a targeted login in a non-SSL environment with optional load-balancing. The login-only web engine services only the login requests. The remaining web engines under web director control, service all other requests. This configuration puts the entire burden of servicing login requests on the specified login-only web engines. The HTTP protocol is used for communications between the web client and the web server.

For the login-only web engines, set the web director parameters in the web engine ‘<Host_Name>-web[#].cfg’ as follows:

• UseDirector: AfterLogin
• WebDirectorSlumpName: (do not change this value)
• WillingnessValue: 0
• RedirectingURL: (the preappended protocol value can either be missing or ‘http’)

For the nonlogin web engines, set the web director parameters in the web engine ‘<Host_Name>-web[#].cfg’ as follows:

• UseDirector: Before Login
• WebDirectorSlumpName: (do not change this value)
• WillingnessValue: [1 through 10]
• RedirectingURL: (the preappended protocol value can be either missing or ‘http’)

Targeted SSL Login in a Mixed Environment with Optional Load-Balancing

You can use web director for a targeted SSL login in a mixed SSL/non-SSL web environment with optional load-balancing. Every web-login request is redirected and serviced by the SSL web engines, while other requests being serviced by the non-SSL web engines. The HTTPS protocol must be used for all communications between the web client and the SSL web engines.

Set Up SSL Login Environment

Setting up SSL allows web transactions to be encrypted, providing maximum security for sensitive data, especially passwords. Depending on your configuration type, you can implement an SSL login environment on the configured CA SDM servers.

Follow these steps:

1. Log in to the following server, depending on your CA SDM configuration:
   • Advanced Availability: Application server
   • Conventional: Primary or secondary server
2. Verify that the server has successfully imported an SSL certificate.
3. Create a copy (including subdirectories) of the directory ‘$NX_ROOT/bopcfg/www/wwwroot’, and assign it the following name:

   ‘$NX_ROOT/bopcfg/www/wwwrootsec’

4. Add a new virtual directory for the web server named CAisdsec.
5. Point this virtual directory to the following physical directory:

   ‘$NX_ROOT/bopcfg/www/wwwrootsec’

6. Verify that the virtual directory permissions for CAisdsec match the CAisd virtual directory permissions for the script execution. Enforce SSL for the CAisdsec virtual directory.

   Note: In this example, CAisdsec is user-defined and can be renamed.

7. Save the changes.

   Note: Webdirectors do not use a ‘<Host_Name>-web[#].cfg’ file. However, web engines require a unique ‘<Host_Name>-web[#].cfg’ file. Sample web.cfg files are automatically generated while running the configuration. You can import the customizations in the original web.cfg to the new web configuration files by specifying the original web.cfg as the template file you want to use.

8. Copy and save the following files, because a backup of these files is useful whenever you decide to restore the original environment:
   • $NX_ROOT/pdmconf/pdm_startup.tpl
   • $NX_ROOT/pdmconf/pdm_startup
   • $NX_ROOT/bopcfg/www/web.cfg file
   • Any existing primary-web[#].cfg files
   • $NX_ROOT/bopcfg/www/CATALINA_BASE/webapps/CAisd/WEB-INF/web.xml and web.xml.tpl
   • For a secondary server configuration, save backup copies of any existing $NX_ROOT/bopcfg/www/web.cfg or <Secondary_Server_Host_Name>-web[#].cfg files and $NX_ROOT/bopcfg/www/CATALINA_BASE/webapps/CAisd/WEB-INF/web.xml*
9. For each web engine assigned to a webdirector, ensure that the parameters (<Host_Name>-web[#].cfg 'webdirector') of the web engine are set correctly by examining the file in a text editor. If necessary, modify the ‘webdirector’ parameter values to reflect the web engine role you want. Then copy them to the directory: $NX_ROOT/bopcfg/www.
10. Move all $NX_ROOT/samples/pdmconf/primary-web[#].cfg files to the $NX_ROOT/bopcfg/www directory.

    For the secondary server configuration, Move all $NX_ROOT/samples/pdmconf/’secondary_server_name-web[#].cfg’ from the primary server to the secondary server $NX_ROOT/bopcfg/www directory

11. For the servlet server like Tomcat, CA SDM creates web.xml files that can replace the web.xml file on each server hosting a webengine. These files are name primary-web.xml. Rename the files and copy them to the directory: $NX_ROOT/bopcfg/www/CATALINA_BASE/webapps/CAisd/WEB-INF directory.

    For the HTTP server like IIS or Apache, create copies of ‘pdmweb.exe’ in the $NX_ROOT/bopcfg/www/wwwroot directory, a ‘pdmweb[#].exe’ for each web engine, and a ‘pdmweb_d[#].exe’ for each webdirector that has been configured. Verify that the ‘pdmweb[#].exe’ and ‘pdmweb_d[#].exe’ are named according to the correct CGI I/F values (for example: ‘pdmweb1.exe’, ‘pdmweb2.exe’, pdmweb_d1.exe’, and so on).

12. If you are using IIS and want to add Server Extensions for each CGI interface, you can take the file primary-site.dat file and copy it to your $NX_ROOT/bopcfg/www directory as site.dat. When the system is reconfigured these sites is added to IIS.
13. Reconfigure the primary server without reinitializing the database and start services.
14. After reconfiguring verify that the current settings are valid. Start the CA SDM daemons. Verify that there are no errors in the stdlog files. Use pdm_status to view the daemons and their status. Use http://localhost:8080/CAisd/pdmweb.exe to access the system.
15. For Knowledge Management to CA SDM integration, if SSL has been enforced for CA SDM, the CA SDM URL protocol value must be changed.
    1. From the Knowledge Tool Settings Manager, General, Integration, change the CA SDM URL protocol value from http to https.
    2. Save and exit.
16. Open a web browser to the CA SDM login page and verify that a user can log in and that the expected redirect/login behavior is observed.

Implement SSL Login Environment

To implement the SSL login you have set up, make changes to the web director parameter values.

Follow these steps:

1. For Secure Login Web engines, edit the <Host_Name>-web[#].cfg as follows:
   1. Change the CAisd parameter value from /CAisd to /CAisdsec.
   2. Change the UseDirector parameter value from Yes to AfterLogin if the web director uses pass through an authentication.
   3. Change the Willingness parameter value from 5 to 0.
   4. Verify that the RedirectingURL value protocol is listed as https.
   5. Change the Redirecting URL <cgi directory> value from CAisd to CAisdsec.
   6. Save the changes.
2. For non-secure web engines handling all other activity, edit the <Host_Name>-web[#].cfg files as follows:
   1. Verify that the CAisd parameter value is /CAisd.
   2. Change the UseDirector parameter value from Yes to BeforeLogin.
   3. Maintain the Willingness value of 5 or set it to any integer value from 1 to 10, depending on the particular loading weight desired.
   4. Verify that the RedirectingURL value protocol is listed as http.
   5. Verify that the RedirectingURL <cgi directory> value is CAisd.
   6. Save the changes.

      After the configuration, restart Service Desk. After the service restarts, test the login by accessing the non-ssl web engine using HTTP. Verify if it automatically redirects you to the HTTPS secure webengine for the login. Once you are logged in, it automatically redirects you back to the non-ssl HTTP webengine for the normal Service Desk activity.

Verify SSL Login Environment

You can verify the SSL login environment for web engines.

Follow these steps:

• The secure-login web engines must reside in the physical directory that is mapped to the SSL-enforced virtual directory (CAisdsec in this example).

  For secure-login web engines, create instances of pdmweb.exe in the $NX_ROOT/bopcfg/www/ wwwrootsec directory with the name of pdmweb[#].exe. The executable name must match the CGI I/F value for each secure-login web engine.

  Example: If you have assigned the CGI I/F value of the secure-login web engine to pdmweb2, create a physical copy of pdmweb.exe, and rename it pdmweb2.exe.

• The non-secure web engines and web directors must reside in the physical directory that is mapped to the non-SSL virtual directory CAisd.

  For non-secure web engines and web directors, create instances of pdmweb.exe in the $NX_ROOT/bopcfg/www/wwwroot directory. A copy of pdmweb.exe must exist for each non-secure web engine and webdirector configured. Rename the copies so that the new names of the executables match the CGI I/F values that have been defined for the web engines and web directors.

  Example: If you have assigned the CGI I/F value of pdmweb3 to the non-secure web engine and the value of pdmweb_d1 to the web director, then create two copies of pdmweb.exe. Rename the first copy to pdmweb3.exe, and then rename the second copy to pdmweb_d1.exe.

Set Up SSL Login for Tomcat Server

Configure SSL on Tomcat Servers in your CA SDM environment.

Follow these steps:

1. To create a key store on each CA SDM server that requires an SSL certificate, perform the following steps:

   Note: A keystore is a store or storage unit for certificates, in which the certificates are imported to, and then Tomcat points to use that keystore and certificates for SSL.

   1. Create a directory under the C: drive (or the local drive you want) with the name, certificates.
   2. Using the command line, navigate to the JRE bin directory (for the JRE installed with Service Desk - usually /SC/JRE)
   3. Run the command "keytool -genkey -alias tomcat -keyalg RSA -keystore c:/certificates/keystore.jks".
   4. Fill in the fields as appropriate (make sure to note what you filled in each filed as you may need this information later).

      A keystore.jks file is created in the C:\certificates\ directory.

2. Generate the Certificate Request for each server. Perform the following steps to generate the certificate request:
   1. Using the command line, navigate to the JRE bin directory (for the JRE installed with Service Desk - usually /SC/JRE)
   2. Run the command "keytool -certreq -alias tomcat -keystore c:/certificates/keystore.jks -file servername-certreq.csr"

      A .csr file is created in the c:/certificates directory on each server where you generated the certificate request.

   3. Send the .csr files to the vendor of your choice who will then generate the appropriate certificates you need based on the certificate request, for each server.

      Note: The certificate you receive from each is different. Some vendors will send you multiple certificated possibly including a root certificate, an intermediate certificate, and a certificate of authority. Each vendor has different instructions on which certificates they provide need to be imported into the keystore. So the key here is to ask the specific vendor that you used to generate the certificates for you, for specific instructions on how to import their certificates into a tomcat keystore.

      Once you received the specific instructions from the vendor, you can follow those to import the appropriate certificates into the keystore on each server. Once that is complete, you can now configure Tomcat on the Service Desk side of things to point it to that keystore where the certificates have been imported.

3. Open the \bopcfg\www\CATALINA_BASE\conf\server.xml file using a text editor and locate the following:

   <-- <Connector port="8443" maxHttpHeaderSize="8192"
   maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
   enableLookups="false" disableUploadTimeout="true"
   acceptCount="100" scheme="https" secure="true"
   clientAuth="false" sslProtocol="TLS"
   keystoreFile="keystoreFile="C:\Documents and Settings\user\.keystore"
   keystorePass="password"/> -->
   

4. Change the code to the following:

   <Connector port="8443" maxHttpHeaderSize="8192"
   maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
   enableLookups="false" disableUploadTimeout="true"
   acceptCount="100" scheme="https" secure="true"
   clientAuth="false" sslProtocol="TLS"
   keystoreFile="keystoreFile="C:\certs\keystore.jks"
   keystorePass="password"/>
   

   Note: Be sure to remove the <-- and --> tags that currently comment out the HTTPS/SSL connector for Tomcat, and set the appropriate path and password for your keystore that you generated in the beginning.

5. Save the server.xml file.
6. Restart Tomcat by using the following commands:

   pdm_tomcat_nxd -c stop
   pdm_tomcat_nxd -c start
   

   Note: We recommend you to restart all the CA SDM servers to ensure that the Tomcat is restarted.

7. Test your tomcat SSL connection by opening a browser and navigating to the Service Desk URL, using the HTTPS protocol, and the tomcat port. For example, use the following URL:

   https://servername:8080/CAisd/pdmweb.exe
   

   The Service Desk Login Screen should open. You have successfully configured SSL on Tomcat.