Re: HTTPAPI failing -suspect TLS

Peter,

We had a customer with a similar issue on V7R1 with our GETURI software.
Here's a link to an article I wrote about it:

http://www.fieldexit.com/forum/display?threadid=170

In a nutshell, V7R1 didn't play nice with settings for the SSL APIs. We
had to update our software to specifically tell it which TLS version to
use.

The default setting for calling the SSL APIs was zero (0) which meant "use
the system value". That didn't work when the system was told to use TLS
v1/2. When we updated our application so the user could set the version
and use TLSv1 or v2, it worked fine.

You may want to post this on the HTTPAPI mailing list. It's possible Scott
has something similar in his software you can use. (Maybe that's what
those extra parms are for).

You may also want to look for a PTF that solves this issue. This was a
while ago and I'd hope they have fixed it (it is fixed in V7R2 and up).
Maybe a call to IBM would help.

Brad
www.bvstools.com

On Tue, Jul 26, 2016 at 5:46 AM, Peter Connell <Peter.Connell@xxxxxxxxxx>
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



##############################################################
This correspondence is for the named person's use only. It may contain
confidential or legally privileged information, or both. No confidentiality
or privilege is waived or lost by any mistransmission. If you receive this
correspondence in error, please immediately delete it from your system and
notify the sender. You must not disclose, copy or rely on any part of this
correspondence if you are not the intended recipient. Any views expressed
in this message are those of the individual sender, except where the sender
expressly, and with authority, states them to be the views of Veda. If you
need assistance, please contact Veda :-
Australia http://www.veda.com.au/contact-us
New Zealand http://www.veda.co.nz/contact-veda
##############################################################

--
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.