System SSL
The System SSL component of the z/OS® Cryptographic Services element provides support for the System Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. This support is required by applications that must use SSL directly through System SSL or by taking advantage of the AT-TLS functions of the Communication Server. SSL/TLS can be used to set up a trusted channel to another system through a potentially insecure network.
In the certified configuration, TLS processing must be configured as described in the following list. A variable within parentheses identifies the attribute or environment variable that controls the setting.
For an OSPP 4.3 evaluation, the certified configuration can use the TLSv1.2
protocol. For an EAL4 or EAL5 evaluation, the certificated configuration can use either TLSv1.2 or
TLSv1.3.
- For TLS V1.2, the following is allowed in the evaluated configuration:
- Ciphers (GSK_V3_CIPHER_SPECS_EXPANDED):
- C024 - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- C02C - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- Supported elliptic curve groups (GSK_CLIENT_ECURVE_LIST,
GSK_SERVER_ALLOWED_KEX_ECURVES):
- 0024 - secp384r1
- 0025 - secp521r1
- Digital signatures (GSK_TLS_SIG_ALG_PAIRS,
GSK_TLS_CERT_SIG_ALG_PAIRS):
- 0403 - SHA-256 with ECDSA
- 0503 - SHA-384 with ECDSA
- 0603 - SHA-512 with ECDSA
- Ciphers (GSK_V3_CIPHER_SPECS_EXPANDED):
For TLS V1.3, the following is allowed in the evaluated configurations:- Ciphers
(GSK_V3_CIPHER_SPECS_EXPANDED)
:- 1302 - TLS_AES_256_GCM_SHA256
Supported elliptic curve groups (GSK_CLIENT_ECURVE_LIST):- 0024 - secp384r1
- 0025 - secp521r1

Supported key shares (GSK_SERVER_TLS_KEY_SHARES,
GSK_CLIENT_TLS_KEY_SHARES)
:- 0024 - secp384r1
- 0025 - secp521r1
- Digital signatures
(GSK_TLS_SIG_ALG_PAIRS,
GSK_TLS_CERT_SIG_ALG_PAIRS)
:- 0403 - SHA-256 with ECDSA
- 0503 - SHA-384 with ECDSA
- 0603 - SHA-512 with ECDSA

- Ciphers
- Certificate processing:
- x.509 client and server certificates must be Elliptic Curve (ECC) NIST Curve 384 or 521, with SHA-384 or 512 signatures. These certificates must be managed by RACDCERT (connected to a RACF key ring) and with private keys that are stored in the ICSF public key data set (PKDS). The certificate to be used during the handshake is identified by its label (GSK_KEY_LABEL), or is the default certificate for the RACF key ring. The RACF key ring must also contain any certificate authority certificates that are needed to validate the partner certificate when requested. Use GSK_KEYRING_FILE to identify the RACF key ring.
- Any certificates in use must conform to RFC 5280 (GSK_CERT_VALIDATION_MODE=5280).
- The client certificate that contains the extended key usage extension must specify the client authentication capability.
- The server certificate that contains the extended key usage extension must specify the server authentication capability.
- Any application that uses TLS with client or server authentication must be configured for revocation checking through OCSP responses. For information about configuring OCSP, see the topic “Enabling OCSP support” in z/OS Cryptographic Services System SSL Programming.
- The client application must enable server domain name validation (GSK_REFERENCE_ID_DNS). For
information about setting up and using server domain name validation with System SSL:
- For z/OS 2.5, see APAR OA63164.
- For z/OS 3.1 and later, see z/OS Cryptographic Services System SSL Programming.
- The server application that requests client authentication must require a certificate from the client (GSK_CLIENT_AUTH_NOCERT_ALERT=ON) and use RACF to map the certificate to a RACF user ID. For more information about user ID mapping, see the topic Using a hostIdMappings extension in z/OS Security Server RACF Security Administrator's Guide.
- Disable server renegotiation (GSK_RENEGOTIATION=DISABLED).
- Disable session resumption by setting the session timeout to 0
(GSK_V3_SESSION_TIMEOUT=0) and disabling server session tickets
(GSK_SESSION_TICKET_SERVER_ENABLE=OFF)
.