Troy,

Have you checked to see if maybe the SSL certificate they are using is a
wildcard one (ie *.domain.com)?

The base SSL APIs (which apparently are used by the FTP client on the IBM i
still) don't play nice with wildcard certificates. The GSKit APIs do.

I was told last year to stop using the "legacy" SSL APIs because of this.
Which tells me they're not going to update them.

It's a longshot... but that issue did cause some very weird error messages
(that made no sense) until I switched my applications over to use GSKit
that worked with SNI and wildcard certs.


Bradley V. Stone
www.bvstools.com
MAILTOOL Benefit #3 <https://www.bvstools.com/mailtool.html>: No 400 byte
or less message limit as with SNDDST or SNDSMTPEMM.

On Mon, Feb 24, 2020 at 3:44 PM B Stone <bvstone@xxxxxxxxx> wrote:

-97 is SSL_ERROR_BAD_CIPHER_SUITE.

It shouldn't be this hard. Has IBM helped with traces/debugging?


Bradley V. Stone
www.bvstools.com
MAILTOOL Benefit #1 <https://www.bvstools.com/mailtool.html>: Command and
ILE Interfaces available which means easily sending email from your
programs.

On Mon, Feb 24, 2020 at 3:28 PM Troy Hyde <troy.hyde@xxxxxxxxxxx> wrote:

Boy wouldn't I love to move to sftp but the vendor doesn't support it.

I apologize in advance for the verbosity of this message.

I've gone back and asked our contact to confirm setup with the vendor.
The information I've been dealing with and have been posting here is
inaccurate at best.

Here's what I'm now told:
1. The connection must be an Explicit Passive Mode FTP-S connection with
TLS v1.2. connect to TCP21. (This is in opposition to the insistence
that is was implicit)
2. Supported ciphers on their side:
0x003D - TLS_RSA_WITH_AES_256_CBC_SHA256
0x0035 - TLS_RSA_WITH_AES_256_CBC_SHA
3. Signing Algorithm: sha256RSA
Key Usage: HANDSHAKE, DATAENCRYPT
Key Type: RSA
Key Size: 2048

With the changes I've implemented as described below, I'm getting a -97
message. The server side has been able to provide this trace:

Trace begin
21 -> 5251 <0.001 756 Rsp: 220-This is a restricted system and is
for the express use by...
21 <- 5251 0.127 86 Req: AUTH TLS
21 -> 5251 <0.001 114 Rsp: 234 Security environment established -
ready for negotiation
21 <- 5251 0.071 141 TLS1.2: HSHK( CLIENT_HELLO )
21 -> 5251 <0.001 52 Ack Psh Win=65533 Seq=2177834785
Ack=4113049937 TimeStamp
21 -> 5251 <0.001 4378 TLS1.2: HSHK( SERVER_HELLO CERTIFICATE...
21 <- 5251 <0.001 76 Ack Psh Fin Win=65535 Seq=4113049937
Ack=2177834785 TimeStamp
21 -> 5251 <0.001 52 Ack Psh Win=65533 Seq=2177839111
Ack=4113049938 TimeStamp
21 -> 5251 <0.001 52 Ack Psh Rst Win=65533 Seq=2177839111
Ack=4113049938 TimeStamp
Trace end
They point out that we are disconnecting ("Fin" on the 3rd to last line)
after they provide the certificate (the 4th to last line).

Everything below here is the current IBM i setup. The top section is
through the browser based Digital Certificate Manager. The last bit is
current system values.

Based on the information provided from the vendor, I created a new
client application in the digital certificate manager with the following
settings:
SECURE SESSION section
Protocols: TLS 1.2
Cipher Specifications: RSA_AES_256_CBC_SHA256
Signature Algorithms for Key Exchange:
RSA_SHA256
RSA_PSS_SHA512
RSA_PSS_SHA384
RSA_PSS_SHA256
ECDSA_SHA512
ECDSA_SHA384
ECDSA_SHA256
ECDSA_SHA224
RSA_SHA512
RSA_SHA384
RSA_SHA224
ECDSA_SHA1
RSA_SHA1



CERTIFICATE VALIDATION section
Signature Algorithms for Key Certificate:
RSA_SHA256
RSA_PSS_SHA512
RSA_PSS_SHA384
RSA_PSS_SHA256
ECDSA_SHA512
ECDSA_SHA384
ECDSA_SHA256
ECDSA_SHA224
RSA_SHA512
RSA_SHA384
RSA_SHA224
ECDSA_SHA1
RSA_SHA1
RSA_MD5
Define the CA Trust List: Yes

Trusted Certificate Authorities: The two certificates provided by the
vendor.
I have not assigned any certificates to the application.

------------------------------
Current system values:
QSSLCSLCTL =
*USRDFN

QSSLPCL =
*TLSV1.2
*TLSV1.3

QSSLCSL =
10 *RSA_AES_256_CBC_SHA256
20 *AES_128_GCM_SHA256
30 *AES_256_GCM_SHA384
40 *CHACHA20_POLY1305_SHA256
50 *ECDHE_ECDSA_AES_128_GCM_SHA256
60 *ECDHE_ECDSA_AES_256_GCM_SHA384
70 *ECDHE_RSA_AES_128_GCM_SHA256
80 *ECDHE_RSA_AES_256_GCM_SHA384




On 2/18/2020 3:34 PM, Patrik Schindler wrote:
Hello Troy,

Am 18.02.2020 um 22:16 schrieb Troy Hyde <troy.hyde@xxxxxxxxxxx>:

We have asked about the port and they confirmed it is correct. It's
one of the first things we considered.
https://en.wikipedia.org/wiki/FTPS

990 is FTP with mandatory SSL (implicit),
21 is unencrypted FTP with optional SSL aka STARTTLS.

That's about the same as 465 is SMTP with mandatory SSL and 25 is SMTP
plaintext with STARTTLS as option.

After reading about firewall incompatibilities, I'd opt to migrate to
sftp which doesn't have all this additional port mess with firewalls in
between not knowing about which ports to enably dynamically (because of the
encrypted command channel).

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc




--

Troy Hyde

FLEX | Manager, Application Standards and Upgrades

800 262 3539

8520 South Sandy Parkway | Sandy, UT 84070

troy.hyde@xxxxxxxxxxx <mailto:troy.hyde@xxxxxxxxxxx>| www.flexcutech.com
<http://www.flexcutech.com>


Facebook <https://www.facebook.com/flexcutech/> Twitter
<https://twitter.com/FLEXCUTech> LinkedIn
<https://www.linkedin.com/in/troyhyde/>

Confidentiality Notice: This communication and any associated
attachments is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential
or otherwise protected from disclosure. Dissemination, distribution or
copying of this communication and any accompanying attached information
by anyone other than the intended recipient(s), or an employee or agent
acting on behalf of the intended recipient, is strictly prohibited. If
you have received this communication in error, please notify us
immediately by replying to this message, and then delete it from your
computer.

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