Our Products:   CompleteFTP  edtFTPnet/Free  edtFTPnet/PRO  edtFTPj/Free  edtFTPj/PRO
0 votes
2k views
in .NET FTP by (51.1k points)
A user reported the following exception:
EnterpriseDT.Net.Ftp.Ssl.SSLFTPException: The certificate could not be verified: o - A certification chain processed correctly but terminated in a root certificate not trusted by the trust provider.
   at am.a(BaseSocket A_0)
   at EnterpriseDT.Net.Ftp.Ssl.SSLFTPClient.Auth(SSLFTPSSLVersion sslVersion, Boolean secureDataChannels)
   at EnterpriseDT.Net.Ftp.SecureFTPConnection.SecureConnection()
   at EnterpriseDT.Net.Ftp.SecureFTPConnection.Connect()

1 Answer

0 votes
by (51.1k points)
My response:

This error is usually caused by non-matching certificates. In other words, the certificate that was installed is not the same as the one being sent by the server.

As you probably know, server validation is intended to prevent attacking servers from being able to masquerade as the genuine server, so you obviously must not exclude the possibility that the reason why it is failing is that someone is attempting to divert your traffic to a fake server. It's highly unlikely but if we are not vigilant then there's really not that much point in server validation since that is it intended purpose.

In actual fact, I have never heard first-hand of this happening and the cause is usually human error somewhere along the way. Fortunately it's fairly easy to check the certificates manually because we do actually have access to the certificates that are sent by the server.

SSLFTPException has a property, CertificateChain, that contains all the certificates sent by the server during the SSL handshake process. The first certificate in the array is the server's certificate and the last certificate is the root certificate. You can write each certificate to a file using the WriteToCER method.

You can then open this file by double-clicking on it, which will open the Windows certificate viewer. In this way you can inspect the various attributes of each certificate and compare them with those of the certificate that you've installed into the Windows certificate store. Check the Issuer, Subject, Valid from date, Valid to date, as well as the Serial number. In your case I think the last certificate in the chain should match the certificate that you've installed.

You can also install any of these certificates into the store itself and try validating the server again, which will usually work. Of course, if you do this you have to be sure that the certificate that you install is the genuine article. This could, for example, be done by having the server administrators inspect the certificate and let you know whether or not it is one of theirs.

- Hans (EnterpriseDT)

Categories

...