Considerations when using an external CA

When you must use an external CA, there are two possible approaches. The first approach is to request only an intermediate CA certificate from the external CA and then use it to sign only an individual server certificate for each RRSF node. This approach is similar to the approach described in Using an internal CA to sign a server certificate for each RRSF node.

The second approach when using an external CA is to generate a request for a server certificate for each RRSF node and send those requests to the external CA. When returned, add each server certificate and CA certificate to the key ring for each RRSF node. If the CA is well known, the CA certificate might already reside in the RACF® database. If so, connect it to the key ring of each node and mark it as trusted. Remember that any server presenting a certificate signed by this CA certificate will be accepted as a valid RACF node. Therefore, the following guidelines for increased security apply to the second approach when you lack exclusive use of the signing CA certificate:

Guidelines:

Ensure that the SAFCheck level of client authentication is specified in the Communication Server AT-TLS policy for RRSF. This level requires that you map each RRSF server certificate to a RACF user ID. To do this, you can use the hostIdMapping certificate extension if it is available from your external CA or if you use PKI Services. Otherwise, you can add a certificate name filter on each node for every other node or add each server certificate to the RACF database of every other node. If your installation propagates digital certificate information using an existing RRSF APPC connection, the task of adding each server certificate to the RACF database of every other node can be automatically performed for you. (For important RRSF considerations, see Before you begin.) If propagation is not available, using certificate name filters requires the least administrative effort. (For details, see Certificate name filtering.)
If your external CA might issue other certificates using the same CA certificate used to issue your server certificates, implement a one-to-one certificate filter for each server certificate. This ensures that no other issued certificate will match your filter's distinguished name (DN). If you are confident that the external CA will not issue other certificates with the same DN, you can reduce administrative effort by implementing a single many-to-one filter on each node based on the naming convention used for the distinguished names of your RRSF servers.
Protect a resource named IRR.RRSF.CONNECT in the RRSFDATA class. Be sure to give the mapped user ID at least READ access to it even if the user ID has the TRUSTED or PRIVILEGED attribute. This RRSFDATA profile can also be used to create a RACF audit trail that logs the establishment of inbound RRSF connections to the local system.