× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. WEB400
  3. October 2020

Re: SSL API Issues after latest CUM PTFs on V7R3

Thanks for following up. I haven't heard from my customers yet either
(which I normally take as a good thing).

I wonder if in our applications if a handshake fails we should have a
default number of retries. The only issue is I can't recreate the issue on
my end to test with.

On Tue, Oct 6, 2020 at 7:59 AM Gerald Magnuson <gmagqcy.midrange@xxxxxxxxx>
wrote:

The PTF (MF67570) didn't fix it.

On Mon, Oct 5, 2020 at 1:48 PM Brad Stone <bvstone@xxxxxxxxx> wrote:

Keep up updated on your issues and if the PTF IBM suggest solves the
issue.

On Mon, Oct 5, 2020 at 1:43 PM Gerald Magnuson <
gmagqcy.midrange@xxxxxxxxx

wrote:

Also, not only are we getting the TLSv1.2 Peer not recognized...
errors
when connecting to our internal servers (HAProxy), were have been
getting that -16 error when we try to connect to one of our VANs
(COVISINT).

On Mon, Oct 5, 2020 at 1:22 PM Gerald Magnuson <
gmagqcy.midrange@xxxxxxxxx

wrote:

We have had these errors since we went to 7.4 on Labor Day. After
changing ciphers and putting on all the latest PTF groups, we now
have
this very strange symptom: these errors "(GSKit) Peer not
recognized
or
badly formatted message received." are only happening between the
hours
of 6am through 10am (we may get 1 or 2 outside of this time frame).

I have just installed that ptf (MF67593 - 7.4 MF67570), so let's see
what
tomorrow brings.

On Thu, Oct 1, 2020 at 4:07 PM Brad Stone <bvstone@xxxxxxxxx> wrote:

Info from IBM that a customer got:

-APAR MA48442 (“OSP-OTHER-UNPRED SYSTEM TLS FAILS TLSV1.2 SERVER
HELLO
WITHOUT EXTENSION DATA LENGTH”)
-Update a few PTF Groups to current levels
-Apply PTF MF67593, which isn’t in any PTF Group.

So it does seem to be an IBM issue that has already been (hopefully)
fixed. I will know for sure after the weekend.

I tried searching for PTFs but that seems futile these days...
unless
I'm
just not understanding how their newer searches work...lol.

On Thu, Oct 1, 2020 at 10:07 AM Brad Stone <bvstone@xxxxxxxxx>
wrote:

Hi, Jeff.

I haven't seen any issues with Google, no. I just am wondering if
it's
an
issue with only certain endpoints. It's hard to tell. I am
hoping
to
hear
from one customer to see what IBM tells them.

On Thu, Oct 1, 2020 at 9:36 AM Jeff Crosby <
jlcrosby@xxxxxxxxxxxxxxxx

wrote:

Is this 7.3? Would this possibly affect my using G4G uploading
PDFs?

Asking because I'm set to IPL and apply some PTF groups tomorrow
night.

Thanks.



On Thu, Oct 1, 2020 at 10:23 AM Brad Stone <bvstone@xxxxxxxxx>
wrote:

I have a few customers that seem to be reporting an issue with
the
IBM
SSL
APIs after applying a recent PTF group when using GETURI
(HTTPAPI
also
reports the same issues) communicating with a web service.

Also from tests using cURL and PHP on the IBM i the error
cannot
be
reproduced, neither can it on the PC using Postman, etc.

Randomly they are receiving the error:

415 - Peer not recognized or badly formatted message received.

If the standard SSL APIs are used RC is normally -16 if I
recall.

One customer was able to work with a trading partner and they
did a
trace
on their end and tracked it down to the "Hello" communications
from
the
IBM
i during SSL negotiation.

What they saw and explained was something like this:

"...When everything is working fine we have noticed the server
hellos
are
super small …376 bytes which is an indication of TLS session
reuse.
Then
there is an attempt to do TLS reuse with a different proxy or
backend
server and it fails which is likely this TLS FATAL illegal
parameter
error. The NEXT server hello is much larger, 3586 bytes,
because
the
TLS
session is trashed and has to start over.


It then works for a while with the little server hello's doing
session
reuse ... until a proxy or backend server gets switched and it
blows
up
and
starts all over..."


So, when this error is reported on the IBM i seems to correlate
with
what
they see on their end where the TLS session is "trashed".


My suspicion is that a recent PTF broke this, since it worked
for
years
previously and after the PTFs this behavior started.


I have the customer contacting IBM to see when they can find
with
all
this
information, but I am just curious if anyone else is
experiencing
this
issue and what they have found.


Thanks.


Bradley V. Stone
www.bvstools.com
Native IBM i e-Mail solutions for Microsoft Office 365, Gmail,
or
any
Cloud
Provider!
--
This is the Web Enabling the IBM i (AS/400 and iSeries)
(WEB400)
mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.



--


Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
direct.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion
of
my
company. Unless I say so.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.



As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.