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.

  1. 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')
  2. 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 'MARKN.SHRSERV.GENREQ'.
    RACDCERT GENREQ(LABEL('Shared Server'))
       SITE DSN('MARKN.SHRSERV.GENREQ')
  3. Send the certificate request to the CA and receive the returned certificate from the CA into data set 'MARKN.SHRSERV.CERT'. Start of changeThe 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).End of change

    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.

  4. 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')
  5. 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))
  6. 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 key.
    • When using the FACILITY class:
      1. 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 it.
          SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY)
        • If the FACILITY class is already active and RACLISTed, refresh it.
          SETROPTS RACLIST(FACILITY) REFRESH
      2. Permit the user ID of each server to access the private key. They each need CONTROL access to IRR.DIGTCERT.GENCERT.
        RDEFINE FACILITY IRR.DIGTCERT.GENCERT UACC(NONE) 
        PERMIT IRR.DIGTCERT.GENCERT CLASS(FACILITY) ID(INVSERV FTPD)
            ACCESS(CONTROL)

        Start of changeIf 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.End of change

    • 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 it.
        SETROPTS CLASSACT(RDATALIB) RACLIST(RDATALIB)
      • If the RDATALIB class is already active and RACLISTed, refresh it.
        SETROPTS RACLIST(RDATALIB) REFRESH
  7. 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.
    Server user ID Key ring directive
    INVSERV KEYRING RING01
    FTP KEYRING INVSERV/RING01
    If INVSERV is a z/OS® HTTP Server, set the keyFile directive to:
    KeyFile RING01 SAF 
    Note: RACF® is not involved in this step.