Re: FTPS using self-signed certificate

[Douglas Handy <dhandy@xxxxxxxxx>]

Scott et al,

Other than that, I don't know. This is a problem with understanding the
> SSL packets that it's receiving, which wouldn't be a configuration issue.
> I can only suggest calling IBM if PTFs don't help.


For the sake of the archives, I thought I'd post the resolution.  Turns out
I didn't even need any PTFs to make it work, though IMHO there should be a
change made to the FTP client.

When using the command:

  FTP RMTSYS(xxx) PORT(*SECURE) SECCNN(*IMPLICIT) DTAPROT(*PRIVATE)

then I'd negotiate a secure control channel but the server was not notified
the data channel should be private.  So the server was sending the data
channel in clear text while the client was expecting SSL packets leading to
the SSL errors I was receiving.  The solution was simply to send SECDATA P
after logging in and prior to issuing any command using the data channel
such as GET, PUT, or DIR.  Doing so then caused the server to switch the
data port to private, and everything worked the way it should.

Interestingly, when the command line includes DTAPROT(*CLEAR) instead of the
default DTAPROT(*PRIVATE), then the IBM client automatically sends a SECDATA
C command once your login is successful.  This is evidently to inform the
server you want a clear text data channel.  The ironic thing is that from
what I can tell from RPC2228 or 4217, the server is supposed to assume the
data channel is clear unless/until told to switch to a private data
channel.

Thus, IMHO, the IBM client should send the SECDATA P subcommand for you
automatically after login when using DTAPROT(*PRIVATE), and shouldn't really
need to automatically send SECDATA C when using *CLEAR, though there is no
harm in sending it in both cases.

Those RFC's don't specifically mention *implicit connections though, as it
seems that method has been deprecated in favor of contacting the server on
port 21 and sending the AUTH command prior to the OPEN.  (In the IBM client,
this is the SECOPEN subcommand.)  So I can't say emphatically that it is
correct for a server to assume a clear text data port with implicit
connections, the way it is stated it should with other connections even when
AUTH is used to encrypt the control port.  The *implicit deprecation seems
to be mostly because it eliminates the need for another port to be available
for establishing secure connections (port 990 in this case).  However, with
this server we need to use the *implicit connection method though because
port 21 is blocked at the firewall so it requires making the connection on
port 990 instead.

But the bottom line is sending my own SECDATA P subcommand after logging
onto the host resolved all my problems.

Doug

PS - SupportLine seemed unaware of this too.  They setup comm traces and
determined the "SSL errors" were due to the server sending the data port in
clear text when it expected SSL packets, but then suggested the server was
in error and I needed to take it up with the support desk for the server.
IBM didn't mention the SECDATA subcommand, and I didn't hunt for it until
the server site's support staff told me their server can do either, but by
default the data port starts out clear text unless / until it receives a
command to switch to an encrypted data port.  Once I knew that, finding the
SECDATA P subcommand was easy and everything worked right away.