SSLCACHE
Sharing information about the SSL session across different CICS regions in a sysplex is particularly useful when HTTP requests are being routed across a set of CICS regions by using TCP/IP connection workload balancing techniques, such as TCP/IP port sharing or Sysplex Distributor. Consider using sysplex caching if you have multiple CICS socket-owning regions that accept SSL connections at the same IP address. If appropriate for your CICS systems, using sysplex caching can significantly reduce the number of full SSL handshakes.
- SSLCACHE={CICS|SYSPLEX}
-
- CICS
- The SSL environment for the CICS region includes a local cache of information about the SSL sessions between CICS and clients. z/OS® System SSL manages the SSL environment. This cache is replaced by a new cache when the PERFORM SSL REBUILD command is issued.
- SYSPLEX
-
A cache of SSL sessions is held at sysplex level for multiple CICS regions. This cache is not affected when the PERFORM SSL REBUILD command is issued. You must activate the z/OS System SSL started task GSKSRVR to have a sysplex cache. For details of the SSL started task GSKSRVR and its configuration, see The SSL started task GSKSRVR.
To use the sysplex session cache, each system in the sysplex must be using the same external security manager, and a user ID on one system in the sysplex must represent the same user on all other systems in the sysplex.
To use sysplex caching for TLS 1.3, you must use z/OS 2.5 with APAR OA63252 (HA63252, IA63252, and JA63252) or a later release of z/OS.
Restriction: 6.1 Sysplex caching by using theSYSPLEXoption is not supported for TLS 1.3.
For difference in mechanisms for session caching between TLS 1.2 and TLS 1.3, see Sysplex session cache support (TLS 1.2) in z/OS documentation and Sysplex session ticket cache support (TLS 1.3) in z/OS documentation. For performance comparison between TLS 1.2 and TLS 1.3, see 6.2: TLS comparison.