Creating certificates to encrypt the connection between Db2 for z/OS and Db2 Data Gate

To continue setting up AT-TLS, you need a signer certificate and a server certificate. Use the signer certificate to sign the server certificate. The signer certificate can be a certificate from an external certificate authority (CA), an internal CA, or a self-signed certificate.

About this task

SSL connections require a certificate that identifies the server and that can be used to encrypt the network connections to this server.

In the z/OS operating system, such certificates are managed by RACF®, and are stored in a RACF object called a key ring. You must specify this key ring in your TCPCONFIG data set, so that it can be used by the AT-TLS component.

The certificate that you use can be a certificate issued by an external or an internal certificate authority (CA). Certificates issued by known external CAs have the advantage that they can be validated correctly by connecting clients without completing any prerequisite steps, provided that the CA is known to the client application. Since clients often use predefined libraries that are distributed freely, this is, in many cases, not a problem.

Libraries of internal CAs can usually be linked by client applications within an organization. This also allows you to tap resources of an established infrastructure.

However, if you do not have access to certificates of an external or internal CA, you can create a self-signed certificate. Such certificates require an import on the client side (Db2 Data Gate on IBM Cloud Pak® for Data) because the client application needs to "know" whether the certificate and the server identity behind it can be trusted.

You do not have to create an extra certificate for inbound access because a copy of the certificate for outbound network traffic will be used. Following the process in Generating and exporting a key pair and a certificate for Db2 Data Gate guarantees that the certificates for inbound and outbound network traffic bear the same digital signature because you create only one certificate, export it, and then import a copy of that certificate. Identical signatures on both certificates are mandatory.

The steps in the following topics provide you with all the information needed to create a self-signed certificate and to set up a working AT-TLS connection using this certificate.

If you already have a certificate that you can reuse for this purpose, you can skip the steps that deal with the certificate creation and adapt the steps in which the correct certificate must be specified.

Procedure

  1. In accordance with the following example, add RACF commands to a JCL job that finally create a signer certificate. This certificate is used to sign the server certificate that you create in a later step. If you already have a certificate that can be used for this purpose (from an external or an internal CA), you can skip this step.
    
    RACDCERT CERTAUTH -
    GENCERT -
    SUBJECTSDN(OU('DB2 SERVER CA') -
               O('IBM') -
               C('USA')) -
    NOTAFTER(DATE(2030-12-31)) -
    WITHLABEL('DB2 SERVER CA') -
    KEYUSAGE(CERTSIGN)

    The signer certificate created in this example bears the label 'DB2 SERVER CA'. RACF uses this label to reference the certificate. You must specify the name of this label in a few upcoming configuration steps. Modify the label name to make its purpose easily recognizable within your organization.

  2. Add commands that will create the server certificate and sign it with the signer certificate from step 1.
    • As the owner of this certificate, specify the user ID that starts the DDF started task (DB2USER in the example below).
    • As the canonical name (CN), specify the DNS host name to contact your Db2 subsystem. For a data sharing group, this would be the host name of the group rather than a member host name.
    Here is an example:
    RACDCERT ID(DB2USER) -
    DELETE(LABEL('DB2ASERVER CERTIFICATE'))
    RACDCERT ID(DB2USER) -
             GENCERT   -
             SUBJECTSDN(CN('DB2A') -
                        O('IBM') -
                        C('USA')) -
             ALTNAME(IP(10.9.3.7)) -
             NOTAFTER(DATE(2030-12-31)) -
             WITHLABEL('DB2ASERVER CERTIFICATE') -
             SIGNWITH(CERTAUTH LABEL('DB2 SERVER CA'))
    SETR RACLIST (DIGTRING) REFRESH
    SETR RACLIST (DIGTCERT) REFRESH
    SETR RACLIST (FACILITY) REFRESH
     
    Important: The canonical name (CN) in the server certificate is not verified when Db2 for z/OS and Db2 Data Gate are connected. Any host name will be accepted if the certificate was signed by the CA whose public key is transferred to Db2 Data Gate.