EZD1287I TTLS Error RC: 456 Initial Handshake ACF2 CSFPGKP CSFSERV class
Article ID: 142850
Updated On:
Products
Issue/Introduction
configuring AT-TLS encrypted connection from the mainframe ( client ) to a Linux server.
The linux server is currently configured to use CIPHERS that have not been used before and they require ICSF access. Rules are in place for all callable services
including CSFPGKP CSFSERV resource CSF1GKP.
a portion of a GSK TRACE is below
xxxx MESSAGE 00000004 18:32:08.470434 SSL_ERROR
Job TCPIP Process 0001030A Thread 00000003 crypto_ec_token_generate_key_pair
ICSF service failure: CSFPGKP retCode = 0x8, rsnCode = 0x3e88
xxxx MESSAGE 00000004 18:32:08.470443 SSL_ERROR
Job TCPIP Process 0001030A Thread 00000003 send_v3_client_messages
Unable to generate ECDH key pair: Error 0x03353084
Environment
Release : 16.0
Component : CA ACF2 for z/OS
Resolution
There is a CRYPTO class validation for resource CLEARKEY.SYSTOK-SESSION-ONLY
that needs to allow access to all users for some SSL callable services.
$KEY(CLEARKEY) TYPE(CRY)
SYSTOK-SESSION-ONLY UID(*) SERVICE(READ) ALLOW
without this rule in place, ACF2 would protect the resource by default and would not allow access - thus causing potential problems as described below.
The following statement is in IBM doc
The CLEARKEY.token-name resource within the CRYPTOZ class controls the ICSF
policy for creating a clear key versus a secure key.
When the resource is defined and set to NONE, System SSL's usage of the PKCS #11
callable services to generate keys is restricted to secure keys only.
This causes functions within System SSL to fail.
System SSL uses both explicit tokens and the SYSTOK-SESSION-ONLY omnipresent token.
The following are examples that can fail in this environment in System SSL:
The gskkyman utility or CMS APIs that create ECC or DH (FIPS mode) keys or certificates.
Ephemeral ECDH and Ephemeral DH key exchanges during a SSL/TLS handshake.
Feedback
