Generating certificates by using RACF

You can create a self-signed server certificate on z/OS by using IBM Resource Access Control Facility (RACF).

In general, the best place to obtain certificates is from a well-known Internet certificate authority (CA). However, in certain situations, such as within your test environment, you might want to create your own CA. This section explains how to create a self-signed server certificate on z/OS by using IBM Resource Access Control Facility (RACF). The CA is prepared so that it can be exported and stored in the client. The client requires the CA to verify the authenticity of the server certificate.

CLIST:

Copy Services Manager provides two command lists (CLISTs) that can be used to perform the steps outlined in the following sections: Both sample CLISTs (CERTCRE8.sample and CERTIMPT.sample) are in the following folder:
<TPC-R INSTALL ROOT>/wlp/usr/servers/replicationServer/etc/

The default certificate file (zosKey.p12) that is included with Copy Services Manager is also in this folder. To use this certificate with the CERTIMPT CLIST you must first move it into a z/OS data set.

To move the default certificate into a z/OS data set, use the OGET command, specifying the binary option. The OGET command allows you to copy a z/OS UNIX file from the z/OS UNIX System Services hierarchical file system (HFS) into a z/OS data set.

CERTCRE8.sample:

The CERTCRE8.sample CLIST generates a unique self-signed certificate to represent the certificate authority (CA) and then generates another certificate, which is signed with the first certificate to authenticate the HyperSwap instance on the system (or sysplex) where this CLIST is executed. This certificate is then connected to a key ring on the system where the CLIST is executed so that is available to all systems within the scope of RACF, typically a single sysplex or RACF remote sharing facility (RRSF).

If both Copy Services Manager and HyperSwap are not running within the scope of RACF, which is likely the case, you must import this certificate on all other systems that are managed by Copy Services Manager or where Copy Services Manager might run.

For example, if Copy Services Manager that is running in Sysplex A is managing HyperSwap that is running in Sysplex B and another HyperSwap in Sysplex C, you might want to create a single certificate that Sysplexes A, B, and C share. Alternatively, you might want to create one certificate for the sockets connection between Sysplex A and B and create a second certificate for the connection between Sysplex A and C.

In the first case, you execute the CERTCRE8 CLIST on Sysplex B, and then use CERTIMPT CLIST to import the certificate that you created on Sysplex B to Sysplex C. You might also need to import the certificate to Sysplex A if that sysplex is also running HyperSwap and can be managed by a standby Copy Services Manager that is running outside of the sysplex.

In the second case, you execute the CERTCRE8 CLIST once on Sysplex B and once on Sysplex C. You might also need to execute the CERTCRE8 CLIST on Sysplex A if that sysplex is also running HyperSwap and can be managed by a standby Copy Services Manager running outside of the sysplex.

This CLIST takes two parameters:
USERID
This is the user ID that is associated with the HyperSwap Address Space.
DATASETNAME
The name of the data set to where the certificate will be exported. You can specify any data set name that you want, for example IBMUSER.ZOSKEY.P12.

CERTIMPT.sample:

The CERTIMPT.sample CLIST imports the Copy Services Manager supplied default certificate, a self-signed certificate that was created by using the CERTCRE8 CLIST, or a certificate that was created in some other way. If you choose to import the default certificate that is provided with Copy Services Manager, this is a less secure option, because it uses the same certificate for all Copy Services Manager servers. Using the Copy Services Manager supplied default certificate is less secure than a self-signed certificate, which is less secure than a CA-signed certificate. However it is also an easy option to use.

This CLIST might also be useful to connect two z/OS Systems to the same Copy Services Manager server, and to use the same certificate for both.

This CLIST takes two parameters:
USERID
This is the user ID that is associated with the HyperSwap address space.
DATASETNAME
This is the name of data set from where you will import the certificate. This is typically the same data set name that is specified for the CERTCRE8.sample CLIST (CERTCRE8.sample:). Copy Services Manager also includes a zosKey.p12 file in the same folder. If you use the default certificate, this file must be imported if you are using this CLIST. This file must be put into the data set before running the CLIST.

Considerations: Copy Services Manager not on z/OS:

Sometimes, you might want to deploy Copy Services Manager on a distributed platform. For example, in the case of Metro Global Mirror with HyperSwap, the remote data center might be dark, where z/OS is not normally active unless the workload must be moved there. In this case, having the Copy Services Manager standby running on a distributed server is preferred so that the RECOVER command can be issued, allowing the volumes to be placed in a state where z/OS can be started from them.

In this environment, if you are using the default certificate file that is included with Copy Services Manager, zosKey.p12, it already is located in the proper directory.

If you created a unique certificate, it must be installed in the following directory:

<TPC-R INSTALL ROOT>/wlp/usr/servers/replicationServer/etc/

You can do this by using FTP to transfer the file in binary directly from the MVS data set to the file system of the distributed system.

Another option is to use the OPUT command, specifying the binary option to place the certificate in the z/OS UNIX System Services HFS. Use the OPUT command to copy an MVS data set member into the z/OS UNIX System Services HFS. When it is in the z/OS UNIX System Services HFS, you may use FTP to transfer the file from the z/OS HFS to the distributed system’s HFS.