Security for TCP/IP connections

The scheduler authentication mechanism uses the SSL services of z/OS®. For further details, see z/OS® Cryptographic Services System Secure Sockets Layer Programming.

To enable SSL authentication for your network, perform the following actions:
  1. Create the SSL work directory by using the EQQPCS10 sample JCL. You can use the same directory as the one used for SSL in end-to-end. In the following examples, the directory is /u/tws/ssl
  2. From /u/tws/ssl/ as current directory, open a shell prompt, start the gskkyman utility of z/OS® Cryptographic Services System SSL, and do the following:
    1. Create the keystore database and consider protecting it from unauthorized access, because it has to contain private key and trusted certificates. For example, consider the database /u/tws/ssl/tws1.kdb.
    2. Generate a password file and store it in the SSL directory defined in the previous step, for example /u/tws/ssl/tws1.sth.
    3. At this point you can:
      • Create a certificate request and send it to the Certificate Authority.
      • Store the signed certificate in the database.
      • Import the certificate of the Certification Authority which signed your certificate.

      In this way you have a database containing both your certificate and Certification Authorityʼs one.

      The scheduler uses a default name to identify your certificate; therefore you are not required to set up a multiple database handling. If you need different certificates in order to partition your network from a security point of view, you need different databases. The advantage of this solution is that you can store each database in a different directory, with its own access list.

      Alternatively, you can create your own custom self-signed certificates. For details, see the procedure described in Scenario: configuring TLS with custom self-signed certificates.

  3. Configure HCL Workload Automation for Z, by specifying the TCPOPTS statement for each component of your network. Consider each component according a client-server model. Typically, a client-server group is composed by the trackers and data stores communicating with the corresponding controller, or by a remote interface communicating with the corresponding server.

    When the controller or the server started task communicates with a partner component, the communication is always started by the partner component; therefore the partner acts as a client. Differently from the end-to-end communication, the communicating partners use the same port numbers for both non-SSL and SSL communications. Specify the same TCPOPTS parameters for all the components in a client-server group.

    The following example shows a TCPOPTS definition to activate an SSL support that uses a SAF key ring.
     TCPOPTS 
       . . .
       SSLEVEL(FORCE)                          1
       SSLKEYSTORE(MYKEYRING)                  2
       SSLKEYSTORETYPE(SAF)                    3
       SSLAUTHSTRING('OPCMASTER')              4
       SSLAUTHMODE(STRING)                     5
    In this example:
    1
    The FORCE keyword enables the SSL communication.
    2
    MYKEYRING is the SAF key ring used to connect the security certificates.
    3
    SAF is the type of key ring used.
    4
    OPCMASTER is the string defined as Common Name (CN) in the certificate.
    5
    The STRING keyword enables the check on the CN string.
When designing your configuration from a security point of view, consider that:
  • To enforce your security, you can use the SSLAUTHMODE(STRING), that requires to:
    • Create an SSL certificate for each controller started task. This certificate will be used by the controller and its remote partners. Define the certificate using as Common Name a unique string corresponding to the controller.
    • Create an SSL certificate for each server started task. This certificate will be used by the server and its remote partners. Define the certificate using as Common Name a unique string corresponding to the server.

    The SSLAUTHSTRING must match the information contained in the certificate sent by the partner. To verify it, you can use the gskkyman utility that allows displaying the keys database and SSL certificate content. The certificate CN is returned by gskkyman as the first line of the “Subject”.

  • If you prefer to use SSLAUTHMODE(CAONLY), then you can use a single SSL certificate for all your network.