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



I appreciate the help, Scott.

I actually have seen this before and in my SSL FAQ list I keep,
it say sthat this could in fact be because the server I'm connecting to is
using an obsolete cipher. So in this case I think I would need to enable
the use of an obsolete cipher to test. The problem is, as you probably
know, the cipher names can get quite confusing from system to system. :)

This is what Google inspection for security reports about the server's
certificate (which has 3 CAs in the chain):

The connection to this site is encrypted and authenticated using TLS 1.2,
ECDHE_RSA with P-384, and AES_256_CBC with HMAC-SHA1.
- AES_256_CBC is obsolete. Enable an AES-GCM-based cipher suite.
- The server signature uses SHA-1, which is obsolete. Enable a SHA-2
signature algorithm instead. (Note this is different from the signature in
the certificate.)

I of course have no control over the server in this case, so I guess I was
wondering if this error could also mean that the client is killing the
connection because of the obsolete ciphers.

All other errors like this, whether GSK or Base SSL APIs, from my
experience with this tell me that either one or more ciphers used by the
server aren't available, or are obsolete. I guess I was just looking for
validation that someone else has had the same experience. I know on V7R4
IBM tightens things up as far as obsolete ciphers go for default setup.
But I would need to know/look up which cipher(s) to enable to test my
theory. :)

Thanks again, Scott.

Bradley V. Stone
www.bvstools.com
MAILTOOL Benefit #5 <https://www.bvstools.com/mailtool.html>: Easy setup!
No confusing or obscure setup instructions, directory entries, SMTP users,
aliases or host tables. All you need is TCPIP, a connection to the internet
and you're done!

On Tue, May 12, 2020 at 3:14 PM Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
wrote:

Brad,

RC=406 (GSK_ERROR_IO) occurs when an error occurs during
communication... in other words, the error isn't in the SSL processing,
it's on the call to a socket API to retrieve/send data.

The errno 3426 (ECONNRESET) means that the connection was disconnected,
and it wasn't expected to be. According to standards, the 'reset'
should indicate some sort of protocol error, i.e. the remote server
detected a violation of the protocol, so disconnected you. I've found
this isn't always the case, and remote sites will send a 'reset' to
indicate any sort of problem. I guess we don't live in a perfect world ;-)

Possibly the disconnect is due to the obsolete cipher, as you say?
You could try configuring the system or application to not use that
cipher and see if that helps?

Not sure what else to suggest...

-SK

On 5/12/2020 3:01 PM, B Stone wrote:
I'm getting the following on an SSL handshake with an endpoint:

RC(406) errno(3426)

Now, I can't find exactly what that means except "connection reset".

When I look at the certificate it does say it's using an obsolete cipher.
That's the only reason I could think this issue is occurring as
connection
works via browser.

Running V7R4.

Thanks.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com


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.