idFTP with Secure Channel ?

[rlebeau]

Problem could be in TIdSSLIOHandlerSocketSChannel possibly?

Seems like it, yes. See further below.

If it is, ill have to switch us sadly to another FTP component that can work with these servers and not be OpenSSL dependent.

Indy is not dependent on OpenSSL, it just uses OpenSSL as the default out-of-the-box.
 

Code:

  if IdFTP1.SupportsTLS then
  begin
    Memo1.lines.add('TLS IS SUPPORTED');
    idftp1.DataPortProtection := ftpdpsPrivate;
  end
  else
    Memo1.lines.add('TLS IS NOT SUPPORTED');

Setting DataPortProtection does not need to be done conditionally like that. Just because the server supports TLS does not necessarily mean TLS is actually being used, particularly when using utUseExpliccitTLS. If you assign an SSLIOHandler, you should also set the DataPortProtection as well, and let TIdFTP decide internally whether to encrypt the data connection or not based on whether the control connection is actually encrypted.

Code:

  IdFTP1.list;  /// <--- generates error "session reuse required"

That is not an Indy error message, it is coming from the FTP server itself. Many FTPS-enabled servers expect the data connection to use the same TLS session as the control connection and/or of previous data connections. Indy's OpenSSL-based SSLIOHandler does that, but looking at the SChannel SSLIOHandler's implementation, I don't think it does.

When setting up a data connection, TIdFTP will Clone() the SSLIOHandler of the the control connection. The SChannel SSLIOHandler's implementation of Clone() simply creates a new TIdSSLIOHandlerSocketSChannel object, but does not do anything further to reuse/link the TLS session of the source object to the cloned object. Specifically, it is not sharing a credential handle across multiple connections, it is obtaining a new credential handle for each connection.

I see you have already filed a bug report with the author of the SChannel SSLIOHandler. I have commented on it as well.