Application Transparent Transport Layer Security

Before reading this topic, first read the Application Transparent Transport Layer Security (AT-TLS) topic of the z/OS Communications Server: IP Configuration Guide.

The z/OS® Communications Server TCP/IP stack provides Application Transparent Transport Layer Security (AT-TLS). This allows socket applications that use the TCP protocol to transparently use the Secure Socket Layer protocol (TLS/SSL) to communicate with partners in the network. IP CICS® sockets enabled applications can take advantage of this support. This requires the following:

The TCP/IP stack must support AT-TLS. This can be determined by the TTLS parameter on the TCPCONFIG statement.
An AT-TLS Policy configuration that matches identifiers of the CICS applications that use it. Examples of identifiers that can be used are whether the application is a listener or client, the IP addresses, and the ports that are used for communication. Note that for CICS applications, the AT-TLS identity associated with the AT-TLS environment is always the user ID of the CICS region. This is the case even if individual CICS transactions are running under their own identity.
SSL key rings and certificates must be created for these applications. For CICS applications using SSL, the user ID that is associated with the keyring is that of the CICS region. See the z/OS Communications Server: IP Configuration Guide for the RACF® commands necessary for creating SSL keyrings and certificates. See the z/OS Security Server RACF Security Administrator's Guide for more information about setting up and managing digital certificates.
For policy level or application level (such as GETTID) support that requires mapping SSL Certificates to RACF user IDs see the z/OS Communications Server: IP Configuration Guide for more information.

Careful consideration must be given for IP CICS sockets-enabled applications that act as clients connecting outbound because the AT-TLS policy might not be specific enough to restrict individual CICS users from logging on to and invoking these clients. Additional CICS security controls such as transaction security and resource security can be considered in order to limit users' access to remote hosts. See Example of outbound AT-TLS support for more information.

If a CICS listener is AT-TLS enabled but the client does not use SSL, there is a mismatch; AT-TLS receives unencrypted data when it is expecting encrypted data. In this case, AT-TLS resets the connection. See the Application Transparent Transport Layer Security (AT-TLS) topic in the z/OS Communications Server: IP Configuration Guide for information regarding defining keyrings, client certificates, mapping them to user IDs, permitting users access to keyrings, and other AT-TLS details.

When taking advantage of AT-TLS support, CICS application programmers and TCP/IP administrators must work together to provide the required support. This can also require communication with RACF administrators.