Example showing how to setup a shared server certificate that can be used by multiple applications/products.
search cancel

Example showing how to setup a shared server certificate that can be used by multiple applications/products.

book

Article ID: 134262

calendar_today

Updated On:

Products

ACF2 ACF2 - DB2 Option ACF2 for zVM ACF2 - z/OS ACF2 - MISC

Issue/Introduction

Assumptions

  • A site has two Prod lpars that share ACF2 Databases and two DEVELOPMENT lpars that share ACF2 Databases. 
  • Site has multiple applications that require Keyrings and a Server certificate. 
  • Site would like each application to have it's own Keyring and share the Server certificate with the other applications on both lpars. 
  • Site uses an external Certificate Authority(CA).
  • Site prefers to share the server certificate using RDATALIB resource calls rather than a SITECERT certificate. 


Environment

Release :

Component : CA ACF2 for z/OS

Resolution

Setting up a Shared Server Certificate

This example is for setting up a shared server certificate along with the signing chain of certificates(CERTAUTH) using a third party certificate provider.


In this example CICSPRD will be the application started task logonid that will be using the shared server certificate. Steps 1-3 would be performed on the PROD and DEVELOPMENT lpars. Steps 4-7 would be performed for each application/product's started task logonid.


1. Generate the server certificate using the GENCERT command. Then issue the GENREQ command to generate a certificate request to be sent to a Certification Authority. The GENREQ extracts the subjects distinguished name and the public key from the certificate and puts it in a dataset from which the request is sent to the Certification Authority:


   ACF
   GENCERT dbserv.CERT SUBJ(CN='hostname.company.com' OU='Business Unit' -
     O='Company Inc.' L='City') LABEL(DBServer)
   GENREQ dbserv.CERT DSN(‘hlq.dbserc.cert.request’)


   Note 1: Parameters specified in lower or mixed case are examples and should be set to meet site standards.


2. Submit the GENREQ request dataset (hlq.dbserc.cert.request) to a Third Party Certification Authority, which will create a new certificate with the same distinguished name and public key, but issued and signed by the Third Party Certification Authority. This example assumes the returned certificate that you have received from the Third Party Certification Authority now resides in the dataset ‘THIRD.PARTY.CERT’ on z/OS. This dataset will be INSERTed into the the ACF2 database on PROD and DEVELOPMENT lpars.


   Note: If the CA returns the signed certificate in a PKCS 7 certificate package, the signed certificate and its CA chain of CERTAUTH certificates will be included. The CA CERTAUTH certificates will be inserted along with the signed certificate and have a record id and label in the CERTAUTH.AUTOnnn format, where the nnn is a number from 0 through 1000.


   ACF
   SET PROFILE(USER) DIV(CERTDATA)
   INSERT dbserv.CERT DSN(‘THIRD.PARTY.CERT’) LABEL(DBServer)


3. Skip this step if the CA returned the signed certificate in a PKCS7 package. If the CA returns just the signed certificate(not a PKCS7 package), the CA's root certificate and any intermediate CERTAUTH certificate(s) must be obtained and inserted as CERTAUTH CERTDATA profile record(s). If the CA is external you should be able to get its root certificate from the CA's website, put it in a dataset, and insert the certificate(s) into the the ACF2 database on PROD and DEVELOPMENT lpars:


   ACF
   SET PROFILE(USER) DIV(CERTDATA)
   INSERT CERTAUTH.3rdPartyCA DSN('THIRD.PARTY.CA.CERT') TRUST


4. Create the Keyring. Since this example is using CICSPRD as the application started task logonid that is using the shared server certificate, create a KEYRING that is owned by CICSPRD and connect the CERTAUTH and dbserv certificates.


   * Change 'CICSPRD' to the application/product's started task logonid and  'CICSPRDRing' to the desired ringname for the application/product.


   ACF
   SET PROFILE(USER) DIV(KEYRING)
   INSERT CICSPRD.RING RINGNAME(CICSPRDRing)
   *
   CONNECT CERTDATA(CERTAUTH.3rdPartyCA) KEYRING(CICSPRD.RING) -
           USAGE(CERTAUTH)
   CONNECT CERTDATA(dbserv.CERT) KEYRING(CICSPRD.RING) USAGE(PERSONAL) -
           DEFAULT


5. Create a FACILITY class resource rule to allow the CICSPRD read from its key ring.


   ACF
   SET RESOURCE(FAC)
   COMPILE * STORE
   $KEY(IRR) TYPE(FAC)
    DIGTCERT.LIST UID(UID for CICSPRD logonid) SERVICE(READ) ALLOW
    DIGTCERT.LISTRING UID(UID for CICSPRD logonid) SERVICE(READ) ALLOW


6. Create a RDATALIB resource class resource rule for resource:  <ringOwner>.<ringName>.LST giving CICSPRD logonid UPDATE access in order to enable retrieval of another logonid's private key.


   ACF
   SET RESOURCE(RDA)
   $KEY(CICSPRD) TYPE(RDA)
   CICSPRDRing.LST UID(UID for CICSPRD logonid) SERVICE(READ,UPDATE) ALLOW


   Note: The resource type (R-RRDA) is required to be added to the GSO INFODIR record.


   SET CONTROL(GSO)
   CHANGE INFODIR TYPES(R-RRDA) ADD
   F ACF2,REFRESH(INFODIR)


7. Before attempting to use the defined KEYRING and CERTDATA records, you will need to issue these operator commands to activate them:


    F ACF2,REBUILD(RDA)
    F ACF2,REBUILD(USR),CLASS(P)
    F ACF2,OMVS
    F ACF2,REBUILD(FAC)

Powered by Wolken Software