Configure
ACF2
Security

Configure
ACF2
security to enable use of the SMP/E RECEIVE ORDER command.
cmcm
Configure
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
Broadcom
Automated Order server and Digicert certificates are required. Sample
ACF2
commands are provided to configure the server for use with
SMP/E Internet Service Retrieval
. For detailed command information, see the
ACF2
for z/OS documentation.
Sample
ACF2
commands are provided to configure the server for use with
SMP/E Internet Service Retrieval
. For detailed command information, see the
ACF2
for z/OS documentation.
Before you begin changing your
ACF2
database, ensure that your user ID is authorized to manipulate certificates and keyrings.
2
Configure
ACF2
Security for the Server Certificates
Use the following procedure to configure
ACF2
security for the server certificates.
  1. Confirm that you have completed the procedures to Obtain the Certificates for
    SMP/E Internet Service Retrieval
    .
  2. Create an
    ACF2
    keyring for user1 to be shared with user2 or other users.
    You can use the same keyring for the
    Broadcom
    Automated Order server and
    Broadcom
    Download server. If you use the same keyring, SMP/E only requires that you define the keyring with the <ORDERSERVER>. A keyring is a named collection of certificates that are associated with a specific user. A certificate is identified by its label and the keyring 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 keyring. The ring name can contain mixed-case characters and special characters (!&*¬-%_?:=.). Blanks are not allowed.
      Limits:
      Up to 237 characters
    The keyring is created.
  3. Add the Digicert Intermediate CA certificate to your
    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
    ACF2
    database:
    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
    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 keyring.
    Complete this step after you add the User certificate to the
    ACF2
    database and you have verified the Digicert Intermediate CA certificate is in your
    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 keyrings 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 keyrings 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 keyring with their user certificate and the Digicert certificates. Ensure that SMP/E finds the certificates in the correct keyring when executing the RECEIVE ORDER command.
    • Shared certificates:
      Give user2 permission to read other user keyrings 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 keyring when executing the RECEIVE ORDER command. To complete this step, user2 must specify the keyring name
    and
    the user ID that is associated with the keyring, USER1, on the keyring attribute in the ORDERSERVER data set as follows:
    keyring="user1/smpe_user_keyring"
    This keyring name must match (name and case) the keyring name that is specified in the
    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
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 Keyring 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 keyring or certificates.
For assistance in debugging SMP/E RECEIVE ORDER keyring or certificate issues, contact Broadcom Support and ask for
ACF2
product support. Provide the list of keyrings, list of certificates, and the complete output from the SMP/E RECEIVE ORDER.
Use the following ACF commands to list the keyring and certificates, and to verify their existence and proper attributes.
  • For the keyring:
    1. List the keyring owner and name:
      SET PROFILE(USER) DIV(KEYRING) LIST
      user1.ring
    2. Verify that all certificates are connected to the keyring with USAGE(CERTAUTH).
    3. Verify that the following parameters (keyring owner, keyring 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. This certificate 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.
  1. Complete the following steps as described in Obtain the Certificates for
    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
    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 keyring. 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.