(ZOS) Defining Secure Sockets Layer security for servers

Complete these steps for RACF to authorize the server to use digital certificates. SSL uses digital certificates and public and private keys.

We must request a certificate authority (CA) certificate and a signed certificate for the server. If we plan to implement SSL client certificate support, we must also have certificate authority certificates from each certificate authority that verifies the client certificates. We must have a user ID with the authority to use the RACDCERT command in the Resource Access Control Facility (RACF) (for example, SPECIAL authority).

If the application server uses SSL, we must use RACF to store digital certificates, and we must use public and private keys for the user identities under which the server controllers run.

Tasks

1. For each server that uses SSL, create a key ring for the controller user ID of that server. Example: Your controller is associated with the user ID called ASCR1. Issue the following command:

   RACDCERT ADDRING(ACRRING) ID(ASCR1)
   

2. Receive the certificate for the application server from the certificate authority. Example: You requested that a certificate and the certificate authority returned the signed certificate to you, which you stored in a file called ASCR1.CA. Issue the following command:

   RACDCERT ID (ASCR1) ADD('ASCR1.CA') WITHLABEL('ACRCERT') PASSWORD('password')
   

3. Connect the signed certificate to the controller user ID's key ring and make the certificate the default certificate. Example: Connect the certificate that is labeled ACRCERT to the key ring ACRRING owned by ASCR1. Issue the following command:

   RACDCERT ID(ASCR1) CONNECT (ID(ASCR1) LABEL('ACRCERT') RING(ACRRING) DEFAULT)
   

4. If we plan to have the server authenticate clients (SSL client certificate support):
   1. Receive each certificate authority (CA) certificate that verifies the client certificates. Example: Receive the CA certificate that verifies a client with user ID CLIENT1. That certificate is in a file called USER.CLIENT1.CA. Issue the following command:

      RACDCERT ADD('USER.CLIENT1.CA') WITHLABEL('CLIENT1 CA') CERTAUTH
      

   2. Give each CA certificate the CERTAUTH attribute.

      Connect each client's certificate authority (CA) certificate to the controller user ID's key ring.

      Example: Connect the CLIENT1 CA certificate to the ring ACRRING owned by ASCR1.

      RACDCERT ID(ASCR1) CONNECT(CERTAUTH LABEL('CLIENT1 CA') RING(ACRRING))
      

5. Give read access for IRR.DIGTCERT.LIST and IRR.DIGTCERT.LISTRING in the RACF FACILITY class to the controller user ID. Example: Your controller user ID is ASCR1. Issue:

   PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ID(ASCR1) ACC(READ) 
   PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(ASCR1) ACC(READ)
   

What to do next

We are done with the RACF phase when the RACF commands succeed.

Subtopics

• Set up a keyring for use by Daemon Secure Sockets Layer
  Follow these steps to configure a keyring for use by Daemon Secure Sockets Layer.

• Define SSL security for clients and servers
  Use the steps in this topic to allow the client to use digital certificates.

• SSL considerations for WAS administrators
  The Resource Access Control Facility (RACF) customization jobs create an SSL keyring owned by the WAS for z/OS administrator. This SSL keyring contains the digital certificate needed to communicate with WAS. Other MVS™ user IDs, which require WAS for z/OS administration require additional customization.

Related:

SSL repertoires

Prepare for security at installation time