Scenario 7: Sharing one certificate among multiple servers
This is similar to Scenario 1: Secure server with a certificate signed by a certificate authority with the exception that this scenario involves sharing a single certificate (and its private key) between two servers, the inventory server and the FTP server. The inventory server is associated with the user ID INVSERV, while the FTP server is associated with user ID FTPD.
- Generate a self-signed placeholder certificate for the two servers.
Because this certificate will be shared, it should be associated with
SITE rather than the INVSERV user ID.
RACDCERT SITE GENCERT SUBJECTSDN(CN('xyzzy.com') OU('Shared') O('XYZZY') C('US')) WITHLABEL('Shared Server')
- Create a certificate request to send to your chosen certificate
authority. The certificate request that we are creating is based on
the certificate that we created in the previous step. Place this certificate
into the data set
RACDCERT GENREQ(LABEL('Shared Server')) SITE DSN('MARKN.SHRSERV.GENREQ')
- Send the certificate request to the CA and receive the returned certificate from the CA into
'MARKN.SHRSERV.CERT'. The ADD (data-set-name) parameter specifies the data set containing one digital certificate or certificate package in binary or Base64 format. You must specify a cataloged sequential data set. The record format (RECFM) expected by RACDCERT is variable blocked (VB). When you specify the ADD function, RACDCERT opens the specified data set, and reads in the content to add the certificate(s).
Restriction: The certificate request data contained in the data set must be sent to, and received from, the external CA using the process defined by the CA. Those steps are not included.
- Add the certificate signed by the certificate authority. This
will automatically replace the original self-signed certificate with
the actual certificate.
Attention: Do not delete the self-signed certificate before performing this step.
The example command uses the SITE keyword because the self-signed placeholder certificate was created under SITE and will only be replaced if the SITE keyword is specified on the RACDCERT ADD command. If SITE is not specified, then the certificate is added as a new certificate.
RACDCERT SITE ADD('MARKN.SHRSERV.CERT') WITHLABEL('Shared Server')
- Create a key ring to be shared between the two user IDs. (The
key ring must be associated with a single user ID even though it will
be shared by the two servers. Therefore, associate the key ring with
the user ID of one of the two servers.) Then, connect the shared certificate
to INVSERV's key ring and mark it as the default certificate.
RACDCERT ID(INVSERV) ADDRING(RING01) RACDCERT ID(INVSERV) CONNECT(SITE LABEL('Shared Server') RING(RING01) USAGE(PERSONAL) DEFAULT))
- Protect the shared key ring and the private key of the certificate
by administering a profile in the FACILITY or RDATALIB class and permit
the user IDs of each server access to access the certificate and private
- When using the FACILITY class:
- Permit the user ID of each server to access the key ring. Because the key ring is associated
with INVSERV, the user ID for the inventory server needs only READ access.
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE) PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(INVSERV) ACCESS(CONTROL) PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(FTPD) ACCESS(CONTROL)
- If the FACILITY class is not already active, activate and RACLIST
SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY)
- If the FACILITY class is already active and RACLISTed, refresh
SETROPTS RACLIST(FACILITY) REFRESH
- If the FACILITY class is not already active, activate and RACLIST it.
- Permit the user ID of each server to access the private key. They each need CONTROL access to
RDEFINE FACILITY IRR.DIGTCERT.GENCERT UACC(NONE) PERMIT IRR.DIGTCERT.GENCERT CLASS(FACILITY) ID(INVSERV FTPD) ACCESS(CONTROL)
If the caller's user ID has CONTROL authority to the <ringOwner>.<ringName>.LST resource in the RDATALIB class, than it can extract the private key from a CERTAUTH or SITE certificate.
- Permit the user ID of each server to access the key ring. Because the key ring is associated with INVSERV, the user ID for the inventory server needs only READ access.
- When using the RDATALIB class:
RDEFINE RDATALIB INVSERV.RING01.LST UACC(NONE) PERMIT INVSERV.RING01.LST CLASS(RDATALIB) ID(INVSERV) ACCESS(READ) PERMIT INVSERV.RING01.LST CLASS(RDATALIB) ID(FTPD) ACCESS(UPDATE)
- If the RDATALIB class is not already active, activate and RACLIST
SETROPTS CLASSACT(RDATALIB) RACLIST(RDATALIB)
- If the RDATALIB class is already active and RACLISTed, refresh
SETROPTS RACLIST(RDATALIB) REFRESH
- If the RDATALIB class is not already active, activate and RACLIST it.
- When using the FACILITY class:
- Configure each server to use the shared key ring. Because the
key ring is associated with INVSERV, the KEYRING directive need not
be fully qualified for when you configure the INVSERV server. For
the FTP server, specify the fully qualified name.
If INVSERV is a z/OS® HTTP Server, set the
Server user ID Key ring directive INVSERV
Note: RACF® is not involved in this step.
KeyFile RING01 SAF