[z/OS]

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 about the RACDCERT command, see the z/OS Security Server RACF Command Language Reference for your z/OS version in the z/OS Internet Library.

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 previous step 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.


Ícone que indica o tipo de tópico Tópico de Tarefa



Ícone de registro de data e hora Última atualização: July 9, 2016 7:56
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_definsslsecclient
Nome do arquivo: tsec_definsslsecclient.html