An upgrade of edtFTPnetPRO to v18.104.22.168 from v22.214.171.124 produces different outcomes for different .NET Framework versions when connecting to a TLS 1.0 FTPSEXPLICT server which negotiates a DHE_RSA_AES_128_SHA cipher.
In fact testing shows that only ciphers restricted to those covered by SSLFTPCipherSuite.SECURE_CIPHER will work when using .NET Framework 4.6\4.7. On .NET Framework 4.5 the connection is made successfully without any cipher restriction.
The error thrown is: EnterpriseDT.Mentalis.Security.Ssl.Shared.SslException("The data was not signed by the server certificate.") when validating the certificate.
We used Linqpad versions 4 and 5 separately to uncover that the .NET Framework version was having an effect.
Is this intended? Are the less securely implemented ciphers effectively unavailable for these .NET frameworks?