SSL Error With OS390
PASSPORT PC to Host, PASSPORT Web to Host
TN3270, TN5250
I am getting a "socket receive error-return code 0" error message when trying to establish an SSL connection to my OS/390 system.
If you receive an error message from PASSPORT products when using SSL, such as "SOCKET RECEIVE ERROR - RETURN CODE 0" then the negotiation of the SSL session is failing. Rocket Software has identified the cause of this as an error with the OS/390 Communications Server.
OS/390 Communications Server IP offers support for Secure Socket Layer version 3 (SSLv3) identified by FMIDs (See chart below). These FMIDs identify the level of SSL support and the supported Cipher Suites. Although it is normal to check if the appropriate FMID is available using SMP/E, Rocket Software have identified certain situations when support will not be available, even with the FMID on! To check if this situation applies to your site, code the ENCRYPTion ENDENCRYPTion block in the TCP/IP profile (sample below) using all available Cipher Suites in the appropriate FMID's.
If you detect one or more of the following messages then it is likely that you will have the problem.
EZZ6033I PROFILE WARNING ON PORT n, ENCRYPT TYPE encryption type IS NOT AVAILABLE
EZZ6029I PROFILE ERROR ON PORT n, ALL ENCRYPT OPTIONS UNAVAILABLE
Although these messages apply to R6 & R7 of OS/390 they are not found in the manual until R8.
The following shows the SECUREPORT statements for OS/390 V2R7 with FMID JTCP37K:
|
TELNETPARMS |
|||
|
|
SECUREPORT 9923 KEYRING HFS HFS_keyring_file |
||
|
|
|
ENCRYPT |
|
|
|
|
|
SSL_NULL_Null |
|
|
|
|
SSL_NULL_MD5 |
|
|
|
|
SSL_NULL_SHA |
|
|
|
|
SSL_RC4_MD5_EX |
|
|
|
|
SSL_RC4_MD5 |
|
|
|
|
SSL_RC4_SHA |
|
|
|
|
SSL_RC2_MD5_EX |
|
|
|
|
SSL_DES_SHA |
|
|
|
|
SSL_3DES_SHA |
|
|
|
ENDENCRYPT |
|
|
|
|
- |
|
|
|
|
- |
|
|
|
|
- |
|
|
|
ENDTELNETPARMS |
||
|
SSLv3 Cipher Type |
Base |
JTCP35T |
JTCP35L |
JTCP35K |
|
SSL_NULL_Null |
* |
* |
* |
* |
|
SSL_NULL_MD5 |
* |
* |
* |
* |
|
SSL_NULL_SHA |
* |
* |
* |
* |
|
SSL_RC4_MD5_EX |
|
|
|
* |
|
SSL_RC4_MD5 |
|
|
|
* |
|
SSL_RC4_SHA |
|
|
|
* |
|
SSL_RC2_MD5_EX |
|
* |
* |
* |
|
SSL_DES_SHA |
|
|
* |
* |
|
SSL_3DES_SHA |
|
|
|
* |
IBM has accepted this as an issue and has supplied a PTF for all the relevant security levels (FMIDs). For more information, please visit the IBM OS/390 support web site:
http://techsupport.services.ibm.com/s390/support
When the TCP/IP product was originally shipped, three FMID features were provided to ship the SSL (Secure Sockets Layer) function (JTCP35K, JTCP35L and JTCP35T for V2R6 and JTCP37K, JTCP372, and JTCP373 for V2R7).
Each function shipped a unique part name but used a single CSECT name. So HTCP350/HTCP370 shipped EZBTTCFB and EZBTZCFB, JTCP35L/JTCP372 shipped EZBTTCFN and EZBTZCFN, JTCP35K/JTCP37K shipped EZBTTCF3 and EZBTZCF3, and JTCP35T/JTCP373 shipped EZBTTCFX and EZBTZCFX.
All of these MODs shipped the same CSECT name in the LMODS EZBTTMST, EZBTMCLF and EZBTZMST. This left open the possibility that a BASE PTF shipping its module could replace the feature version of the CSECT thus regressing the level of SSL support.
ssl, security, secure, passtcp, error, socket, return code = 0