Component : CA ACF2 for z/OS
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:
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.
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:
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.
SET PROFILE(USER) DIV(KEYRING)
INSERT CICSPRD.RING RINGNAME(CICSPRDRing)
CONNECT CERTDATA(CERTAUTH.3rdPartyCA) KEYRING(CICSPRD.RING) -
CONNECT CERTDATA(dbserv.CERT) KEYRING(CICSPRD.RING) USAGE(PERSONAL) -
5. Create a FACILITY class resource rule to allow the CICSPRD read from its key ring.
COMPILE * STORE
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.
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.
CHANGE INFODIR TYPES(R-RRDA) ADD
7. Before attempting to use the defined KEYRING and CERTDATA records, you will need to issue these operator commands to activate them: