66 RACF Remote Sharing Facility over TCP/IP
3.4.5 Using an external CA to sign a server certificate for each RRSF node
When you must use an external CA, use one of these approaches.
Request only an intermediate CA certificate from the external CA, and use the certificate
to sign only an individual server certificate for each RRSF node. This approach is similar
to the approach described in 3.4.4, “Using an internal CA to sign a server certificate for
each RRSF node” on page 50.
Use an external CA to generate a request for a server certificate for each RRSF node. It
then sends 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 be in the RACF database. If so,
connect it to the key ring of each node and mark it as trusted.
The following guidelines for increased security apply to the second approach when you
lack exclusive use of the signing CA certificate:
Ensure that the SAF Check level of client authentication is specified in the
Communication Server AT-TLS policy for RRSF.
Using zOSMF configuration assistant, indicate the ‘Client authentication handling’ level
of client authentication in the advanced settings.
These settings specify whether to run the SSL handshake for a server that requires
client authentication. If so, it specifies which of these levels of client authentication to
perform:
Pass-through: Bypasses client certificate validation.
Full: Runs client certificate validation if the client presents a certificate.
Required: Requires the client to present a certificate and runs client certificate
validation. This setting is the default if the server requires client authentication.
Remember: Any server that presents a certificate signed by this CA certificate is
accepted as a valid RACF node.
Chapter 3. Configuring RRSF for TCP/IP 67
SAF Check: Requires the client to present a certificate, runs client certificate
validation, and requires the client certificate to have an associated user ID defined
to the security product (Figure 3-33).
Figure 3-33 SAF Check
This level requires that you map each RRSF server certificate to a RACF user ID. You
can use the hostIdMapping certificate extension for this purpose if it is available from
your external CA or if you use PKI Services.
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. Using certificate name
filters requires less administrative effort.
If your external CA might issue other certificates by using the same CA certificate used
to issue your server certificates, implement a one-to-one certificate filter for each
server certificate. This configuration ensures that no other issued certificate matches
your filter distinguished name (DN). If the external CA will not issue other certificates
with the same DN, reduce administrative effort by implementing a single many-to-one
filter on each node. Base this filter 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.
The keyring must have the server certificate and the signing certificate.

Get RACF Remote Sharing Facility over TCP/IP now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.