Quick reference to configuring SSL in a multitier environment

As an Administrator, if you are familiar with SSL communication in Tivoli Netcool/OMNIbus, you can configure SSL in a multitier environment.

1. Modify the interfaces file and configure SSL ports. Create entries for SSL in the Server editor, or manually define these entries in the omni.dat connections file. Create and distribute the interfaces file. To prevent plain text connections, configure an SSL port and do not use both SSL and plain text ports. Use the following interfaces file as guidance.

   [AGG_P]
   {
   Primary: omnihost1.ibm.com ssl 4101
   }
   [AGG_B]
   {
   Primary: omnihost2.ibm.com ssl 4101
   }
   [AGG_V]
   {
   Primary: omnihost1.ibm.com ssl 4101
   Backup: omnihost2.ibm.com ssl 4101
   }
   [AGG_GATE]
   {
   Primary: omnihost2.ibm.com 4301
   }

   More information.

   • Configuring server communication information
   • Using the Server Editor to configure SSL on UNIX
   • Manually editing the connections data file
2. Create a key database for storing digital certificates on each computer where a server component is installed (a server component can be an ObjectServer, a process agent, or a proxy agent), and on each computer from which clients connect to the server by using an SSL port. Use a dedicated key database file omni.kdb for each Tivoli Netcool/OMNIbus installation on a server or a client computer. Reference the following example to create a key database with the nc_gskcmd utility.
   Create a key database file ($NCHOME/etc/security/keys/omni.kdb on both the AGG_P and AGG_B host servers.

   $NCHOME/bin/nc_gskcmd -keydb -create 
   -db "$NCHOME/etc/security/keys/omni.kdb"
   -pw password -stash -expire 366

   For more information, see Creating a key database.
   Note: Because the command stores the password in the stash file, the -pw password argument can be interchanged with the -stashed option in all the following commands.
3. Create a root CA certificate. If you want to set up a private truest network in which you are acting as the issuing CA for your server certificates, then create a root CA self-signed certificate. Reference the following example to create a root CA self-signed certificate with the nc_gskcmd utility.

   $NCHOME/bin/nc_gskcmd -cert -create 
   -db "$NCHOME/etc/security/keys/omni.kdb" -pw
   password -label "NCOMS_CA" -ca true -dn
   "CN=NCOMS_CA,O=IBM,OU=Support,L=SouthBank,ST=London,C=GB" 
   -expire 366 -x509version 3

4. Distribute a root CA certificate. To use a root CA self-signed certificate as a signer certificate, distribute the certificate to all clients. Extract the certificate from the server key database and then add the extracted certificate to the key database on each client computer. Reference the following sample substeps.
   1. Extract a certificate.

      $NCHOME/bin/nc_gskcmd -cert -extract 
      -db "$NCHOME/etc/security/keys/omni.kdb"
      -pw password -label "NCOMS_CA" -target
      "$NCHOME/etc/security/keys/ncoms-ca-cert.arm"

   2. Transfer the CA certificate to all clients and add the certificate to the key database.

      $NCHOME/bin/nc_gskcmd -cert -add 
      -db "$NCHOME/etc/security/keys/omni.kdb" -pw
      password -label "NCOMS_CA" -file "ncoms-ca-cert.arm"

5. Create a certificate request. From each server computer, create a request for a digital certificate for the server and send the certificate request to a trusted CA for authorization. The CA authorizes the certificate request and uses its self-signed root certificate to generate a server certificate and the CA then returns the signed server certificate. Create a certificate signing request for both AGG_P and AGG_B ObjectServers, see the following sample substeps. Create the signing request on the same host as the ObjectServer for which the certificate is intended, which is omnihost1.ibm.com for AGG_P and omnihost2.ibm.com for AGG_B.
   1. Create a certificate request for AGG_P ObjectServer.

      $NCHOME/bin/nc_gskcmd -certreq -create 
      -db "$NCHOME/etc/security/keys/omni.kdb"
      -pw password -label "AGG_P" -dn
      "CN=AGG_V,O=IBM,OU=Support,L=SouthBank,ST=London,C=GB" -file
      "$NCHOME/etc/security/keys/aggp-certreq.arm"

   2. Create a certificate request for AGG_B ObjectServer. This step must be run on the AGG_B host machine.

      $NCHOME/bin/nc_gskcmd -certreq -create 
      -db "$NCHOME/etc/security/keys/omni.kdb"
      -pw password -label "AGG_B" -dn
      "CN=AGG_V,O=IBM,OU=Support,L=SouthBank,ST=London,C=GB" -file
      "$NCHOME/etc/security/keys/aggb-certreq.arm"

   It is also possible to use the CN values that equal the hostname or the domain name of the host computer, see Sharing certificates.
6. Sign certificate requests by using CA. If you set up a private trust network, reference the following sample substeps to sign each request with the root CA certificate.
   1. Sign a certificate request for AGG_P ObjectServer.

      $NCHOME/bin/nc_gskcmd -cert -sign 
      -db "$NCHOME/etc/security/keys/omni.kdb" 
      -pw password -label NCOMS_CA 
      -target "$NCHOME/etc/security/keys/aggp-cert.arm"
      -expire 366 
      -file "$NCHOME/etc/security/keys/aggp-certreq.arm"

   2. Sign a certificate request for AGG_B ObjectServer. Ensure that "$NCHOME/etc/security/keys/aggb-certreq.arm" is copied to the server that created the root certificate in step 3. Run the command on the same server that created the root certificate. When the command runs successfully, copy the target file "$NCHOME/etc/security/keys/aggb-cert.arm" to the originating server.

      $NCHOME/bin/nc_gskcmd -cert -sign 
      -db "$NCHOME/etc/security/keys/omni.kdb" 
      -pw password -label NCOMS_CA 
      -target "$NCHOME/etc/security/keys/aggb-cert.arm"
      -expire 366 
      -file "$NCHOME/etc/security/keys/aggb-certreq.arm"

7. Add certificates to key database. Upon receipt of the server certificate from the issuing CA, receive the certificate into the key database for the server. The server certificate authenticates the server side of Tivoli Netcool/OMNIbus communications when a client requests a secure connection. Reference the following sample substeps.
   1. Receive a certificate for AGG_P ObjectServer.

      $NCHOME/bin/nc_gskcmd -cert -receive 
      -db "$NCHOME/etc/security/keys/omni.kdb"
      -pw password -file "$NCHOME/etc/security/keys/aggp-cert.arm"

   2. Receive a certificate for AGG_B ObjectServer.

      $NCHOME/bin/nc_gskcmd -cert -receive 
      -db $NCHOME/etc/security/keys/omni.kdb" -pw
      password -file "$NCHOME/etc/security/keys/aggb-cert.arm"

8. Configure a failover gateway AGG_GATE. ObjectServer clients use the server certificate subject Common Name (CN) value to authenticate the server. The aggregation layer consists of a virtual pair of ObjectServers AGG_P and AGG_B, with a virtual name of AGG_V. When the gateway connects to each ObjectServer, the CN value in the certificate that is presented by the server equals AGG_V, which is different from the ObjectServer name. To authenticate the connection, you must add the AGG_V virtual name to the permitted common names property for each ObjectServer in the AGG_GATE gateway properties file. Reference the following sample command to set the Common Names property.

   Gate.ObjectServerA.CommonNames: 'AGG_V'
   Gate.ObjectServerB.CommonNames: 'AGG_V'

   It is also possible to use the CN values that equal the hostname or the domain name of the host computer, see Sharing certificates.
9. Configure extra ObjectServer layers. Complete the following steps to configure an extra ObjectServer collection layer or a display layer. This procedure is almost identical to the procedure for an ObjectServer aggregation layer.
   1. Modify the interfaces file and configure SSL ports. In the interfaces file, modify the host details for the extra ObjectServer and add an SSL port. Reference the following example definition, which is part of the collection layer definition.

      [COL_P_1]
      {
      Primary: omnihost3.ibm.com ssl 4101
      }
      [C_TO_A_GATE_P_1]
      {
      Primary: omnihost3.ibm.com 4301
      }

   2. Follow the guidance in Create key database.
   3. Follow the guidance in Distribute root CA certificate.
   4. Create a certificate request. Complete this step on the ObjectServer host machine. Run the following sample command, replace [NAME] with the name of the ObjectServer being configured.

      $NCHOME/bin/nc_gskcmd -certreq -create 
      -db "$NCHOME/etc/security/keys/omni.kdb"
      -pw password -label "[NAME]" -dn
      "CN=[NAME],O=IBM,OU=Support,L=SouthBank,ST=London,C=GB" -file
      "$NCHOME/etc/security/keys/[name]-certreq.arm"

   5. Follow the guidance in Sign certificate requests by using CA.
   6. Follow the guidance in Add certificates to key database.
   Inter-tier routing gateways such as C_TO_A_GATE_P_1 or A_TO_D_GATE_1 do not require any specific configuration to enable SSL encryption between OjectServers.

   It is also possible to use the CN values that equal the hostname or the domain name of the host computer, see Sharing certificates.

10. Configure an SSL connection between Dashboard Application Services Hub and the user repository that you defined in the realm. This repository can be an LDAP directory or an ObjectServer. The configuration differs and depends on the user repository.
    More information.

    • Configuring an SSL connection to an LDAP server
    • Configuring an SSL connection to the ObjectServer
11. Configure SSL for the event feed to the Web GUI. Create a secure connection between the Web GUI and the ObjectServer so that the feed of event data in to the Web GUI is SSL protected.
    More information. Configuring SSL connections for the event feed from the ObjectServer
12. Replace the default certificate for Web GUI clients, which comes from Dashboard Application Services Hub to authenticate SSL connections to Web GUI clients. Replace this default certificate with one of your own certificates that was created by a CA or a self-signed certificate.
    More information. Replacing the default SSL certificate for connections to Web GUI clients.
13. Configure an ObjectServer SSL connection for IBM Tivoli Netcool/Impact. Complete the following substeps, which refer you to IBM Tivoli Netcool/Impact topics in the IBM Tivoli Netcool/Impact IBM Documentation, see https://www.ibm.com/support/knowledgecenter/SSSHYH.
    1. If you use the ObjectServer as a user repository, complete steps in the IBM Tivoli Netcool/Impact topic Configuring SSL for ObjectServer user authentication.
    2. Configure secure communications for the event feed between an ObjectServer and IBM Tivoli Netcool/Impact. Complete steps in the IBM Tivoli Netcool/Impact topic Enabling SSL communication with the ObjectServer.