This topic applies only on the z/OS operating system.

Defining SSL security for clients and servers

Use the steps in this topic to allow the client to use digital certificates.

Before you begin

Note that this assumes you use z/OS Security Server (RACF) as your security server. You must obtain a copy of the certificate authority (CA) certificate used to sign the server certificates. The server certificates connect your client to the server. You must also have a user ID with the appropriate authority (such as SPECIAL) to use the z/OS Security Server Resource Access Control Facility (RACF) RACDCERT command. For more information on the RACDCERT command, refer to z/OS Security Server RACF Command Language Reference (SA22-7687-05), available at http://www.ibm.com/servers/eserver/zseries/zos/bkserv/r5pdf/secserv.html. For more information on the RACF in general, refer to z/OS Security Server RACF Security Administrator's Guide (SA22-7683-05), available at http://www.ibm.com/servers/eserver/zseries/zos/bkserv/r5pdf/secserv.html.

About this task

Complete the following RACF steps to allow the client to use digital certificates. SOAP, Secure Socket Layer (SSL), and Java Secure Socket Extensions (JSSE) use digital certificates that have public and private keys. If your client uses SOAP, SSL or JSSE, you must use RACF to store digital certificates that have public and private keys for the user identities under which the client runs.

Procedure

  1. For each administrative client program that uses SOAP, create a keyring for the client user ID. For example, if your client is running with a user ID called CLIENTID, issue the following command:
    RACDCERT ADDRING(ACRRING) ID(CLIENTID)
    
  2. The keyring created in the step above must include the public certificate of any certificate authority (CA) certificates that are required to establish trust in the servers to which your administrative client connects to. For each CA certificate complete the following steps:
    1. Determine whether this CA certificate is currently stored in RACF. If so, record the existing certificate label. If not you must:
      1. Receive each CA certificate used to sign a server certificate. For example, to receive the CA certificate that is stored in the USER.SERVER1.CA file and that verifies a server with the user ID SERVER1, issue the following command:
        RACDCERT ADD('USER.SERVER1.CA') WITHLABEL('SERVER1 CA') CERTAUTH
      2. Connect each server's CA certificate to the client user ID's keyring. For example, to connect the SERVER1 CA certificate to the ring ACRRING owned by CLIENTID:
        RACDCERT ID(CLIENTID) CONNECT(CERTAUTH LABEL('SERVER1 CA') RING(ACRRING))
  3. If the servers your administrative client connect to implements SSL client certificate support, you must create certificates for your client and add them to the server keyrings. Refer to Defining SSL security for servers for instructions on setting up keyrings for the servers.
  4. Give READ access for the IRR.DIGTCERT.LIST and IRR.DIGTCERT.LISTRING profiles in the RACF FACILITY class to the client user ID. For example, if your client user ID is CLIENTID, issue the following command:
    PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ID(CLIENTID) ACC(READ)
    PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(CLIENTID) ACC(READ)
    

What to do next

You are done with the RACF phase when the RACF commands have run successfully.




In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic    

Terms of Use | Feedback

Last updated: Sep 20, 2010 10:03:57 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-zos&topic=tsecdefinsslsecclient
File name: tsec_definsslsecclient.html