Re: HTTPAPI failing -suspect TLS

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

Peter,

Please make sure you are using an up-to-date version of HTTPAPI.  Older 
versions would not have supported TLS 1.1 or 1.2 on V7R1.

Its funny that you tell us the versions of everything except HTTPAPI...

CURL and Node.js are not good tests, here, as they use open source SSL 
libraries in PASE rather than the native ones that IBM provides with IBM i.

-SK

On 7/26/2016 5:46 AM, Peter Connell wrote:
> Hi there,
>
> We have recently attempted establishing a new 3rd party connection using HTTPAPI. They are a modern enterprise and use TLS unlike our other 3rd parties others who still use SSL.
> The 3rd party provides both a test and production connection but HTTPAPI fails to connect to the test machine.
> Both our dev and prod machines will connect to the 3rd party prod machine but neither will connect to the test machine.
> The error is the wretched -
> (GSKit) Peer not recognized or badly formatted message received.
> (GSKit) An operation which is not valid for the current SSL session state was attempted.
>
> It should be noted that we cannot connect directly since all connections must go via our proxy server, but that has been a very straight forward matter.
>
> Our V7R1 development and production machines appear to be set up with the same V7R1 PTFs etc, especially the TR6 one for TLS.
> Strangely, we have written a PHP script using CURL and another using a Node.js script which both successfully connect to the 3rd party test machine (via the proxy)
>
> I've done an online TLS test using the tester at https://ssldecoder.org which reports both 3rd party connections as OK , both supporting  the same protocols as follows -
>
> - TLSv1.2 (Supported)
> - TLSv1.1 (Supported)
> - TLSv1.0 (Supported)
> - SSLv3 (Not supported)
> - SSLv2 (Not supported)
> I've used the QSSLPCL system value to try both *OPSYS and *TLSV1 both this makes no difference.
> At present the developer has opted for the using HTTPAPI to submit the request to a Node.js server running in a batch subsystem but that's all a bit too convoluted for my liking.
> We have always used HTTPAPIR4 so it's a shame we can't get it to work.
> Even though it is the version complied in 2009 it does actually work OK when connecting to the 3rd party production machine.
> I've even tried using the optional protocol parameters for https_init(AppID:peSSLv2:peSSLv3:peTLSv1) with sslv2 and sslv3 set off an tlsv1 set on but that makes no difference.
>
> It seems like there is something about the 3rd party test machine that HTTPAPIR4 does not like.
>
> Cheers, Peter