Configure CA ACF2 Security

Configure CA ACF2 security to enable use of the SMP/E RECEIVE ORDER command. A User digital certificate is required to identify a user uniquely to the CA Automated Order server and Digicert certificates are required. Sample CA ACF2 commands are provided to configure the server for use with CA SMP/E Internet Service Retrieval. For detailed command information, see the CA ACF2 for z/OS documentation.
cmcm
Configure CA ACF2 security to enable use of the SMP/E RECEIVE ORDER command. A User digital certificate is required to identify a user uniquely to the CA Automated Order server and Digicert certificates are required. Sample CA ACF2 commands are provided to configure the server for use with CA SMP/E Internet Service Retrieval. For detailed command information, see the CA ACF2 for z/OS documentation.
Sample CA ACF2 commands are provided to configure the server for use with CA SMP/E Internet Service Retrieval. For detailed command information, see the CA ACF2 for z/OS documentation.
Before you begin changing your CA ACF2 database, ensure that your user ID is authorized to manipulate certificates and key rings.
2
Configure CA ACF2 Security for the Server Certificates
Use the following procedure to configure CA ACF2 security for the server certificates.
Follow these steps:
  1. Confirm that you have completed the procedures to Obtain the Certificates for CA SMP/E Internet Service Retrieval.
  2. Create a CA ACF2 key ring for user1 to be shared with user2 or other users.
    You can use the same key ring for the CA Automated Order server and CA Download server. If you use the same key ring, SMP/E only requires that you define the key ring with the <ORDERSERVER>. A key ring is a named collection of certificates that are associated with a specific user. A certificate is identified by its label and the key ring that it is connected to.
    SET PROFILE(USER) DIV(KEYRING) PROFILE INSERT user1.ring RINGNAME(
    yourRingName
    )
    • user1.ring
      Specifies the record ID.
      Example
      : user1.ring
    • RINGNAME(
      yourRingName
      )
      Specifies the name of the key ring. The ring name can contain mixed-case characters and special characters (!&*¬-%_?:=.). Blanks are not allowed.
      Limits:
      Up to 237 characters
    The key ring is created.
  3. Add the Digicert Intermediate CA certificate to your CA ACF2 database:
    SET PROFILE(USER) DIV(CERTDATA) INSERT CERTAUTH.
    yourcertname
    DSN('
    your.mvs.dataset.name
    ') - LABEL(
    your label description
    )
    • yourcertname
      Specifies your Digicert Intermediate CA certificate name.
      Example: user1.ring
    • '
      your.mvs.dataset.name
      '
      Specifies the name of the sequential data set where the Digicert Intermediate CA certificate was uploaded.
    • your label description
      Specifies a 32-character label to be associated with the Digicert Intermediate CA certificate. The label can contain blanks and mixed-case characters. Quotes are not allowed. If a label is not specified, the label field defaults to the uppercase version of the logonid that was specified.
      Example:
      SMPE Digicert Intermediate
    The Digicert Intermediate CA certificate is added to the database.
  4. Add the Digicert Root certificate to your CA ACF2 database:
    This certificate is required before 11:30 pm EST on February 5, 2021.
    SET PROFILE(USER) DIV(CERTDATA) INSERT CERTAUTH.
    yourcertname
    DSN('
    your.mvs.dataset.name
    ') - LABEL(
    your label description
    )
    • yourcertname
      Specifies your Digicert Root certificate name.
      Example: user1.ring
    • '
      your.mvs.dataset.name
      '
      Specifies the name of the sequential data set where the Digicert Root certificate was uploaded.
    • your label description
      Specifies a 32-character label to be associated with the Digicert Root certificate. The label can contain blanks and mixed-case characters. Quotes are not allowed. If a label is not specified, the label field defaults to the uppercase version of the logonid that was specified.
      Example:
      SMPE Digicert Root
    The Digicert Root certificate is added to the database.
  5. Add the User certificate to the CA ACF2 database:
    SET PROFILE(USER) DIV(CERTDATA) INSERT user1.cert DSN('
    your.mvs.dataset.name
    '
    ) - LABEL(
    your label description
    ) TRUST
    • '
      your.mvs.dataset.name
      '
      Specifies the name of the sequential data set where the User certificate was uploaded.
    • your label description
      Specifies a 32-character label to be associated with the User certificate. The label can contain blanks and mixed-case characters. Quotes are not allowed. If a label is not specified, the label field defaults to the uppercase version of the logonid that was specified.
    The User certificate is added to the database.
  6. Alter the User certificate to mark it trusted:
    SET PROFILE(USER) DIV(CERTDATA) CHANGE user1.cert TRUST
  7. Connect the certificates to the key ring.
    Complete this step after you add the User certificate to the CA ACF2 database and you have verified the Digicert Intermediate CA certificate is in your CA ACF2 database.
    SET PROFILE(USER) DIV(KEYRING) PROFILE CONNECT CERTDATA(user1.cert) KEYRING(user1.ring) USAGE(CERTAUTH)
    SET PROFILE(USER) DIV(KEYRING) PROFILE CONNECT CERTDATA(CERTAUTH.yourDigicertCAcertname) KEYRING(user1.ring) USAGE(CERTAUTH)
    SET PROFILE(USER) DIV(KEYRING) PROFILE CONNECT CERTDATA(CERTAUTH.yourDigicertRootcertname) KEYRING(user1.ring) USAGE(CERTAUTH)
  8. Grant user permissions for the shared and non-shared certificates:
    • Non-shared certificates:
      Give user1 permission to read key rings and certificates as shown in the following example:
      $KEY(IRR) TYPE(FAC) DIGTCERT.LISTRING UID(user1 UID string) SERVICE(READ)
      Thus far, your configuration is for non-shared certificates. If you want a specific user to read other user key rings and certificates, complete this step. Repeat this step for more users.
      Repeat all previous steps for each additional user certificate. Each user must have a key ring with their user certificate and the Digicert certificates. Ensure that SMP/E finds the certificates in the correct key ring when executing the RECEIVE ORDER command.
    • Shared certificates:
      Give user2 permission to read other user key rings and certificates as shown in the following example:
      $KEY(IRR) TYPE(FAC) DIGTCERT.LIST UID(user2 UID string) SERVICE(READ) ALLOW DIGTCERT.LISTRING UID(user2 UID string) SERVICE(UPDATE) ALLOW
      The UID string that is coded in the rules can be coded to allow the desired users that are to share the certificate.
  9. Ensure that SMP/E finds the certificate in the correct key ring when executing the RECEIVE ORDER command. To do this step, user2 must specify not only the key ring name, but also the userid that is associated with the key ring, USER1, on the key ring attribute in the ORDERSERVER data set as follows:
    keyring="user1/smpe_user_keyring"
    This ringname must match (name and case) the key ring name that is specified in the CA ACF2 INSERT command.
  10. Activate the KEYRING and CERTDATA records:
    F ACF2,REBUILD(USR),CLASS(P) F ACF2,OMVS(CERTDATA) F ACF2,REBUILD(FAC)
You have configured CA SMP/E Internet Service Retrieval.
Go to Define the ORDERSERVER Input for RECEIVE ORDER.
Optional Post-Configuration Tasks
Complete the following post-configuration task as needed.
Debug Key Ring and Certificate Issues
The following ACF commands can be useful if the SMP/E RECEIVE ORDER command detects errors or failures that are related to your key ring or certificates.
For assistance in debugging SMP/E RECEIVE ORDER key ring or certificate issues, contact Broadcom Support and ask for CA ACF2 product support. Provide the list of key rings, list of certificates, and the complete output from the SMP/E RECEIVE ORDER.
Use the following ACF commands to list the key ring and certificates, and to verify their existence and proper attributes.
  • For the key ring:
    1. List the key ring owner and name:
      SET PROFILE(USER) DIV(KEYRING) LIST
      user1.ring
    2. Verify that all certificates are connected to the key ring with USAGE(CERTAUTH).
    3. Verify that the following parameters (key ring owner, key ring name, and label) are specified with the SMP/E RECEIVE ORDER ORDERSERVER parameter:
      keyring="
      user1
      /
      ringname
      " certificate="
      label
      "
  • For the certificate authority (CA) certificates:
    1. List the CA certificates:
      SET PROFILE(USER) DIV(CERTDATA) LIST CERTAUTH.
      yourDigicertCAcertname
      LIST CERTAUTH.
      yourDigicertRootcertname
    2. Verify that the CERTAUTH certificates specify
      TRUST
      .
  • For the user certificate:
    1. List the user certificate:
      SET PROFILE(USER) DIV(CERTDATA) LIST
      user1.cert
    2. Verify that the user certificate has
      Status: TRUST
      .
    3. Verify that the certificate's
      Subject's Name: CN
      contains the email of the Broadcom Support registered user.
Replace an Expired User Certificate
A User certificate that is obtained from Broadcom Support Online has a finite life span. It expires after one year. The SMP/E RECEIVE ORDER command warns you if the User certificate is to expire within 30 days. The command fails when the certificate expires. When a certificate expires, replace your existing certificate with a new one. The steps to replace an existing certificate with a new one are similar to the steps that you performed when obtaining and adding the first User certificate.
Follow these steps:
  1. Complete the following steps as described in Obtain the Certificates for CA SMP/E Internet Service Retrieval:
    1. Obtain a new user certificate (Import a User Certificate from Broadcom Support).
    2. Upload the User certificate to z/OS.
  2. Delete the existing User certificate from the CA ACF2 database so that you can use the same label for the new User certificate
    :
    ACF SET PROFILE(USER) DIV(CERTDATA) DELETE user1.cert
  3. Add the new User certificate and connect it to your key ring. Follow the steps in the previous procedure.
    You have replaced an expired certificate.
Because the new certificate uses the same label as the existing certificate, no other changes are necessary to ensure that your RECEIVE ORDER command jobs continue to run as expected.