I've been following this thread.
I'm curious if this is a new issue or similar to the one I had back in August 2015.
SSL is a moving target, needs a lot of TLC.
The below PTFs allowed us to change the V7R1 SSL defaults, which then in turn allowed 3rd party apps to work without issue or changes needed.
From old previous thread V7R1 thread.
SSL client connection error - SSL_Handshake(): Peer not recognized or badly formatted message received.
IBM has released two PTFs to resolve SSL client issues, MF60335, SI57332
http://www-01.ibm.com/support/docview.wss?uid=nas35a3400efeeb413d086257e7e007eb665
http://www-01.ibm.com/support/docview.wss?uid=nas24e5145dca463e43586257e6f003c6da7
http://www-912.ibm.com/a_dir/as4ptf.nsf/b3cb9d42f672b70f86256739004afa0f/9d8f3c581309ec3886257e7e007eb678?OpenDocument
http://www-01.ibm.com/support/docview.wss?uid=nas22105ec3f6fa1476986257e74003c6ed6
Applied to R&D, issue resolved.
Make sure you run the special instructions SST Advanced Analysis SSLCONFIG MACRO. !!!!!!
1. Open a character-based interface.
2. On the command line, type STRSST.
3. Type your service tools user name and password.
4. Select option 1 (Start a service tool).
5. Select option 4 (Display/Alter/Dump).
6. Select option 1 (Display/Alter storage).
7. Select option 2 (Licensed Internal Code (LIC) data).
8. Select option 14 (Advanced analysis).
9. Select option 1 (SSLCONFIG).
10. Enter -h
-eligibleDefaultProtocols:10,08,04 or as needed.
If your iSeries is a client, get these two PTFs installed ASAP.
Note:!!!!!!
Not only was my SSL client connection issue resolved, but other apps previously connecting at TLSv1 are now connecting at TLSv1.2 or TLSv1.1.
Also, another app previously connecting TLSv1.0 using RC4 weak cipher now connecting at TLSv1.2 with TLS_RSA_WITH_AES_128_CBC_SHA2
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Monday, November 21, 2016 7:14 PM
To: Midrange Systems Technical Discussion
Subject: Re: IBM SSL errors (was Re: PASE for i ended for signal 6, error code 1.)
Peter,
I don't think the problem you're experiencing is in GSKit. Rather, it is in the IBM crypto routines that both GSKit and the SSL APIs call. People have been reporting a plethora of problems with SSL in 7.1 since IBM added support for TLS 1.1 and 1.2.
There are far fewer complaints with 7.2/7.3, if that helps.
Node.js and most other PASE-based programs do not use the IBM crypto, but instead use the open source OpenSSL toolkit.
I could potentially write code in HTTPAPI to make it use OpenSSL as well, which would surely eliminate the problem. But, this would take a lot of my time, and I'm not sure it's worth it, since 7.2/7.3 work so much better.
As usual, though, Open Source software (OpenSSL) is much more robust and better supported than commercial (IBM crypto, GSKit, SSL APIs, etc).
-SK
On 11/21/2016 6:02 PM, Peter Connell wrote:
Thanks Scott,
No, we've not experienced any handshake problems at V7R1 on incoming HTTP requests to the Apache server.
Just outgoing via GSK apis. So I'm no wiser.
I didn't realize that IBM appears to support Node given that they now
supply the folder /QOpenSys/QIBM/ProdData/Node It appears that quite a simple node JS script can avoid the GSK errors. Just can't compile it into RPGLE like GSK.
Cheers, Peter
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
midrange.com
