An upgrade of edtFTPnetPRO to v9.2.0.20 from v8.6.5.20 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?
