SSL/TLS encrypted communication

External (client-host) communication using RSE can be encrypted using SSL (Secure Socket Layer) or Transport Layer Security (TLS). This feature is disabled by default and is controlled by the settings in ssl.properties. Refer to "(Optional) ssl.properties, RSE SSL encryption" in the Host Configuration Guide (SC23-7658).

RSE daemon and RSE server support different mechanisms to store certificates due to architectural differences between the two. This implies that SSL definitions and certificates are required for both RSE daemon and RSE server. A shared certificate can be used if RSE daemon and RSE server use the same certificate management method.

Table 1. SSL certificate storage mechanisms
Certificate storage	Created and managed by	RSE daemon	RSE server
key ring	SAF compliant security product	supported	supported
key database	z/OS® UNIX's gskkyman	supported	/
key store	Java™'s keytool	/	supported

Note: SAF-compliant key rings are the preferred method for managing certificates.

SAF-compliant key rings can store the certificate's private key either in the security database or by using ICSF (Integrated Cryptographic Service Facility), the interface to System z® cryptographic hardware.

ICSF is recommended for the storage of the private keys associated with digital certificates, because it is a more secure solution than non-ICSF private key management. ICSF ensures that private keys are encrypted under the ICSF master key and that access to them is controlled by general resources in the CSFKEYS and CSFSERV security classes. In addition, operational performance is improved because ICSF utilizes the hardware Cryptographic Coprocessor. See Cryptographic Services ICSF Administrator's Guide (SA22-7521) for more details about ICSF and how to control who can use cryptographic keys and services.

RSE daemon uses System SSL functions to manage SSL encrypted communications. This implies that SYS1.SIEALNKE must be program controlled by your security software and available to RSE via LINKLIST or the STEPLIB directive in rsed.envvars.

The RSE user ID (stcrse in the following sample commands) needs authorization to access his key ring and the related certificates when SAF-compliant key rings are used for either RSE daemon or RSE server.

RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcrse)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcrse)
SETROPTS RACLIST(FACILITY) REFRESH

The DSTORE_SSL_ALGORITHM variable in the _RSE_JAVAOPTS directive of rsed.envvars lets you choose between SSL and its successor TLS as encryption method, as documented in "Defining extra Java startup parameters with _RSE_JAVAOPTS" in the Host Configuration Guide (SC23-7658).

See Setting up SSL and X.509 authentication for more details on activating SSL for Developer for System z.

Note: The Developer for System z client and host must have access to common encryption protocols (SSLv3 or TLS) and common cipher suite definitions to be able to set up encrypted communication. For information on Java cipher suite definitions used by the client and RSE server, see the developerWorks® Java technology security information site (http://www.ibm.com/developerworks/java/jdk/security/). For information on System SSL cipher suite definitions used by RSE daemon, see Cryptographic Services System SSL Programming (SC24-5901).

By default, RSE daemon relies on System SSL defaults for supported encryption protocols and cipher suite definitions. You can alter these defaults by specifying GSK_PROTOCOL_* and GSK_V3_CIPHER_SPECS* environment variables in rsed.envvars. For information on these environment variables, see Cryptographic Services System SSL Programming (SC24-5901).

Feedback