Scenario 4: Secure server-to-server session enablement

A company wants to use two different secure servers for two different applications. The first application is for its internal employee data, which allows employees to read their own information, and allows designated employees to modify information. This server is called internal_ss. The company also has an external secure server, which is used by client applications running on the customer's systems, to order materials and check the status of orders. This server is called external_ss. The internal_ss server executes with a user ID of INSS, and accepts certificates only from the company's internal certificate authority, whose name is ACME Local Certificate Authority. The external_ss server executes with a user ID of EXSS, and accepts certificates from either the internal certificate authority called ACME Local Certificate Authority or the external certificate authority called Really Big Certificate Authority. Really Big Certificate Authority's certificate is in the data set 'REALBIG.CERTIF'.

The commands to accomplish this are shown below. The authority checks that are shown assume that the person who issues these commands does not have SPECIAL authority, and is neither the user ID INSS or the user ID EXSS.

Create the user IDs for the secure servers.
```
ADDUSER INSS
ADDUSER EXSS
```
Authority required: CLAUTH for the USER class and JOIN in the default group to which they are connected.
Create the internal certificate authority.
```
RACDCERT CERTAUTH GENCERT SUBJECTSDN(CN('ACME CA') O('ACME') C('US'))
   WITHLABEL('ACME')
```
Authority required: CONTROL to the IRR.DIGTCERT.GENCERT and IRR.DIGTCERT.ADD resources in the FACILITY class.
Add the external certificate authority certificate.
```
RACDCERT CERTAUTH ADD('REALBIG.CERTIF') TRUST WITHLABEL('Really Big')
```
Authority required: CONTROL to the IRR.DIGTCERT.ADD resource in the FACILITY class.
Generate the server certificates and the associated private keys. On platforms other than z/OS, this is performed using a facility such as mkkf, ikeyman, or equivalent. On z/OS, this is performed using the RACDCERT GENCERT command. To generate the certificates for the two servers, these two RACDCERT commands are required:
```
RACDCERT ID(INSS) 
         GENCERT  
         SUBJECTSDN(CN('Internal Secure Server') C('US'))
         WITHLABEL('INSS-001')
         SIGNWITH(CERTAUTH LABEL('ACME'))

RACDCERT ID(EXSS)
         GENCERT
         SUBJECTSDN(CN('External Secure Server') C('US'))
         WITHLABEL('EXSS-001')        
```
The internal server certificate was signed by the internal certificate authority. However, the external server certificate must be signed by the "Really Big" external certificate authority. To do that, follow Steps 2 - 6 in Scenario 1 replacing the ID and LABEL values specified with ID(EXSS) and LABEL('EXSS-001').

Authority required: UPDATE to the resources IRR.DIGTCERT.ADD and IRR.DIGTCERT.GENREQ in the FACILITY class, along with CONTROL to the resource IRR.DIGTCERT.GENCERT in the FACILITY class.
Create key rings for the secure servers.
```
RACDCERT ID(EXSS) ADDRING(RING01)
RACDCERT ID(INSS) ADDRING(RING01)
```
Authority required: UPDATE to the resource IRR.DIGTCERT.ADDRING in the FACILITY class.

Connect the certificates to INSS's key ring.

RACDCERT ID(INSS) CONNECT(ID(INSS) LABEL('INSS-001') RING(RING01) DEFAULT)
RACDCERT ID(INSS) CONNECT(CERTAUTH LABEL('ACME') RING(RING01))

Authority required: CONTROL to the resource IRR.DIGTCERT.CONNECT in the FACILITY class.

Connect the certificates to EXSS's key ring.

RACDCERT ID(EXSS) CONNECT(ID(EXSS) LABEL('EXSS-001') RING(RING01) DEFAULT)
RACDCERT ID(EXSS) CONNECT(CERTAUTH LABEL('ACME') RING(RING01))
RACDCERT ID(EXSS) CONNECT(CERTAUTH LABEL('Really Big') RING(RING01))

Authority required: CONTROL to the resource IRR.DIGTCERT.CONNECT in the FACILITY class.

Give user INSS permission to read its own key ring by administering a profile in either the FACILITY or the RDATALIB class.
- When using the FACILITY class:
```
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE) 
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(INSS) ACCESS(READ)
```
  - If the FACILITY class is not already active, activate and RACLIST it.
```
SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY)
```
  - If the FACILITY class is already active and RACLISTed, refresh it.
```
SETROPTS RACLIST(FACILITY) REFRESH
```
- When using the RDATALIB class:
```
RDEFINE RDATALIB INVSERV.RING01.LST UACC(NONE)
PERMIT INSS.RING01.LST CLASS(RDATALIB) ID(INSS) ACCESS(READ)
```
  - If the RDATALIB class is not already active, activate and RACLIST it.
```
SETROPTS CLASSACT(RDATALIB) RACLIST(RDATALIB)
```
  - If the RDATALIB class is already active and RACLISTed, refresh it.
```
SETROPTS RACLIST(RDATALIB) REFRESH
```
Configure INSS's software to use RING01 for SSL. For example, for z/OS® HTTP Server, set the keyFile directive to KeyFile RING01 SAF.
Note: RACF® is not involved with this step.

Give user EXSS permission to read its own key ring by administering a profile in either the FACILITY or the RDATALIB class.

When using the FACILITY class:

PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(EXSS) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH

When using the RDATALIB class:

PERMIT EXSS.RING01.LST CLASS(RDATALIB) ID(EXSS) ACCESS(READ)
SETROPTS RACLIST(RDATALIB) REFRESH

Configure EXSS's software to use RING01 for SSL. For example, for z/OS HTTP Server, set the keyFile directive to KeyFile RING01 SAF.
Note: RACF is not involved with this step.