Creating Secure Sockets Layer digital certificates and System Authorization Facility keyrings that applications can use to initiate HTTPS requests

You can create Secure Sockets Layer (SSL) digital certificates and System Authorization Facility (SAF) keyrings that applications can use to initiate HTTPS requests.

1. If you are using Resource Access Control Facility (RACF®) as your security server, you can generate a personal keyring to be used by your HTTPS application by specifying:

   RACDCERT ID(ASSR1) GENCERT  SUBJECTSDN(CN('J2EE SERVER') O('Z/OS WEBSPHERE') 
   L('POUGHKEEPSIE') SP('NEW YORK') C('US')) SIZE(512) 
   WITHLABEL('ASSR1 SERVER CERTIFICATE') SIGNWITH(CERTAUTH LABEL('PVT CA'))
   

   In this example, the certificate authority used to generate the unique servant region certificate is the same one used to generate the certificates for the WebSphere Application Server for z/OS servers by the customization job.

2. Create a keyring with the same name used for the control region user ID:

   RACDCERT ADDRING(S1GRING) ID( ASSR1 )

   The new keyring is owned by the servant user ID for the certificate authority certificate and the servant server certificate.
3. You must have a certificate authority certificate (a certificate from a certificate authority). You might choose to use the same certificate authority to generate a certificate used by HTTPS applications, which is similar to the certificate used for WebSphere Application Server runtime processing. The certificate authority certificate that is used to create the digital certificates is used by the WebSphere Application Server Runtime, and is created during system customization (and can be created by the WebSphere z/OS Profile Management Tool or the zpmt command). You can connect this certificate authority certificate to the keyring you just created by specifying:

   RACDCERT ID(ASSR1) CONNECT (RING(S1GRING) LABEL('PVT CA') CERTAUTH)

   For this example:

   • S1GRING represents the RACF keyring
   • ASSR1 represents the servant user ID
   • PVT CA represents the certificate authority

   Note that if the target of the request is another WebSphere Application Server for z/OS server, you must also import the certificate authority certificate used by the WebSphere Application Server for z/OS HTTPS repertoire (which is generally set up during customization) into your keyring if it is different than the certificate signer. If authentication using client certificates is requested, you must also import the certificate authority of your application into the HTTPS repertoire.

4. Connect the personal certificate to your keyring:

   RACDCERT ID(ASSR1) CONNECT(ID(ASSR1) LABEL('ASSR1 SERVER CERTIFICATE') RING(S1GRING) DEFAULT)

   For this example:

   • S1GRING represents the RACF keyring
   • ASSR1 represents the servant user ID
   • ASSR1 SERVER CERTIFICATE represents the server certificate for servant user ID
5. Enter the customizable information that needs to be unique across a sysplex.
   This can include the:

   • Subject's public key
   • Subject's Distinguished Name (which uniquely identifies an entity in an X.509 certificate)
     • Common Name
     • Title
     • Organization name
     • Organizational Unit name
     • Locality name
     • State or Province name
     • Country
   • Distinguished Name of the certificate authority that is issuing the certificate
   • Date from which the certificate is valid
   • Expiration date of the certificate
   • Version number
   • Serial number
6. Verify the output of your customization jobs to see what is set up.
   Look at HLQ.DATA.(BBOWBRAK, BBOSBRAK if they were saved), and record the settings of the certificate authority certificate label, the servant region's started task identity. If you wish to use an existing repertoire definition for web services, the keyring name created.