The sysplex session cache support makes SSL server session information available across the sysplex. An SSL session established with a server on one system in the sysplex can be resumed using a server on another system in the sysplex if the SSL client presents the session identifier obtained for the first session when initiating the second session. A server executing in FIPS mode cannot resume a session cached in non-FIPS mode. SSL V3, TLS V1.0 and higher TLS protocol server session information can be stored in the sysplex session cache while SSL V2 server session information and all client session information is stored only in the local SSL cache for the application process.

A client which established a TLS V1.0 or higher TLS protocol session with negotiated TLS extensions to a server can only be resumed on a server which supports the same set of TLS extensions established in the original session. For example, if the original session negotiates the use of the maximum fragment length TLS extension, but the session is later resumed with a server that does not support the maximum fragment length TLS extension, a full rehandshake occurs.

In order to use the sysplex session cache, each system in the sysplex must be using the same external security manager (for example, z/OS® Security Server RACF®) and a user ID on one system in the sysplex must represent the same user on all other systems in the sysplex (that is, user ID ZED on System A has the same access rights as user ID ZED on System B). The external security manager must support the RACROUTE REQUEST=EXTRACT,TYPE=ENVRXTR and RACROUTE REQUEST=FASTAUTH functions.

The sysplex session cache must be enabled for each application server that is to use the support. This can be done by defining the GSK_SYSPLEX_SIDCACHE environment variable or by calling the gsk_attribute_set_enum() routine to set the GSK_SYSPLEX_SIDCACHE attribute. The session information for each new SSL V3, TLS V1.0, TLS V1.1, or TLS V1.2 session created by the SSL server is then stored in the sysplex session cache and can be referenced by other SSL servers in the sysplex. The RACF user associated with the SSL server becomes the owner of the session information. Any SSL server running with the same RACF user can access the session information. SSL servers running with a different RACF user can access the session information if they have at least READ access to the GSK.SIDCACHE.<owner> profile in the FACILITY class.

For example, session information created by RACF user APPLSRV1 can be accessed by RACF user APPLSRV2 if APPLSRV2 has READ access to the GSK.SIDCACHE.APPLSRV1 profile in the FACILITY class. These RACF commands grant this access:

RDEFINE FACILITY GSK.SIDCACHE.APPLSRV1 UACC(NONE)
PERMIT GSK.SIDCACHE.APPLSRV1 CLASS(FACILITY) ID(APPLSRV2) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH