View previous topic :: View next topic
|
Author |
Message |
Davide
New User
Joined: 27 Mar 2008 Posts: 6 Location: Milano
|
|
|
|
Hi to all,
we are in ZOS 1.9 and we have a problem with our Secure Telnet in SSL,
the messages are:
STC08854 EZZ6035I TELNET DEBUG DETAIL CLIENT 927
IP..PORT: 10.88.1.129..26218
CONN: 0044EDB7 LU: MOD: EZBTTSMT
RCODE: 6002-00 SSL/TLS handshake failed.
PARM1: 000001F7 PARM2: 00000000 PARM3: GSK_SECURE_SOCKET_INIT
What can I do? What can I check?
Thanks!
Davide |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Did you recently upgrade anything?
Is that a valid ip address? What happens if you try to PING that ip address?
Have you talked with your network support people? |
|
Back to top |
|
|
Davide
New User
Joined: 27 Mar 2008 Posts: 6 Location: Milano
|
|
|
|
Hello,
Did you recently upgrade anything?
Last month from ZOS 1.7 to ZOS 1.9
Is that a valid ip address?
Yes it is!
What happens if you try to PING that ip address?
The PING is not authorized from our Firewall
Have you talked with your network support people?
About what?
Thanks!!!! |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
I found an IBM Troubleshooting Technote that might apply:
Quote: |
Cause
Error code 6002 reported in the message indicates that the SSL handshake process performed between the server and the client failed. This handshake for the server is performed by the System SSL component of z/OS, and can indicate a problem with the certificates being used (either locally or by the client system) or the SSL configuration. Some common causes are as follows:
* Expired certificates such as:
o server certificate
o the client certificate (if CLIENTAUTH is configured)
o any of the certificates used in signing these.
* When using a locally created (self-signed) certificate instead of a well-known certificate authority, that root certificate must be available and marked as trusted on the keyring of both the client and server.
* The server certificate must be on the keyring, marked as the default certificate and must contain the private key.
Diagnosing the problem
Enable DEBUG DETAIL in the applicable Telnet parameters section (TELNETGLOBALS, TELNETPARMS, or PARMSGROUP). When a subsequent failure occurs, an EZZ6035I message will be generated with additional details about the failure: EZZ6035I TELNET DEBUG DETAIL CLIENT 101 IP..PORT: aa.bb.cc.dd..ppp CONN: xxxxxxxx LU: MOD: EZBTTSMT RCODE: 6002-00 SSL/TLS handshake failed. PARM1: nnnnnnnn PARM2: 00000000 PARM3: GSK_rrrrrrrrrrrr
The PARM1 value (which is in hexadecimal) will be the SSL Function Return Code indicating the nature of the failure. PARM3 identifies the System SSL API call that returned this failure. The most common routines are:
* GSK_ENVIRONMENT_INIT, which is most likely due to setup or access (SAF/RACF) to the specified KEYRING.
* GSK_SECURE_SOCKET_INIT, which is likely due to a rejection of (one of) the certificate(s) being used.
Additional diagnostic data can be obtained by collecting a System SSL trace. The GSKSRVR CTRACE must be used to capture this, which requires having the GSKSRVR started task active before starting TN3270 (or TCPIP, if running the server in the stack). The sample proc provided in the SGSKSAMP library can be used without modification if no other features are going to be enabled.
Review the certificates being accessed on both the server and the affected clients. If using a Unix Key Database, then the gskkyman command should be used to report the certificate contents. If using RACF keyrings to store the certificates, then the RACDCERT command (from an appropriately authorized user) should be used. For clients or security products from other vendors, consult their documentation. |
|
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
Have you talked with your network support people?
About what?
|
About resolving the handshake problem. . . In many (most) organizations, connection problems are handled by network support.
Quote: |
Did you recently upgrade anything?
Last month from ZOS 1.7 to ZOS 1.9 |
And this worked correctly during testing?
What is trying to connect that fails? Some desktop? |
|
Back to top |
|
|
Davide
New User
Joined: 27 Mar 2008 Posts: 6 Location: Milano
|
|
|
|
Hi,
About resolving the handshake problem. . . In many (most) organizations, connection problems are handled by network support.
the ip add. arrive on mainfraime so there is no problem on the network
Quote:
Did you recently upgrade anything?
Last month from ZOS 1.7 to ZOS 1.9
And this worked correctly during testing?
Yes and other customers with different ip add. work on this server
What is trying to connect that fails? Some desktop?
It is a pc with an emulator like Personal Communication of IBM. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Is CLIENTAUTH configured? If so, does the PC have a signed certificate? Since it's only the one machine having the problem, that points pretty strongly to the issue being something related to the PC, it's certificates, and it's SSL connections. |
|
Back to top |
|
|
Davide
New User
Joined: 27 Mar 2008 Posts: 6 Location: Milano
|
|
|
|
Is CLIENTAUTH configured? If so, does the PC have a signed certificate?
Yes and it have a certificate of Verisign
Since it's only the one machine having the problem, that points pretty strongly to the issue being something related to the PC, it's certificates, and it's SSL connections.
Thanks!! |
|
Back to top |
|
|
|