Primary Connection and Data Connection Certificates Don't Match

[G_Hosa_Phat]

Hello, forum members. One of my clients has recently started getting the above-mentioned error message in the FileZilla Client software when connecting to my FTP server (WS_FTP Server by Ipswitch). Now, before we go pointing to a server misconfiguration, I bring this to these forums for a few reasons:

1. This is the only one of my clients experiencing (or at least reporting) this issue, and I know there are other clients using the FileZilla Client software.
2. I use the FileZilla Client software myself and am unable to reproduce the error connecting to the same server.
3. This error has only recently started occurring (within the last couple of days). Before that, the user was able to connect to the same server without error.
4. My FTP server logs show the user successfully connecting, but do not show any errors indicating any problems with that connection.

To resolve this issue, I've tried the following:

1. Verified that the SSL certificate for my FTP server is still valid (it expires in approximately 10 months).
2. Reviewed all of the settings regarding SSL/TLS in the server configuration.
3. Verified the connection settings in the user's FileZilla Client software by comparing them to the settings in my Site Manager.
4. Cleared the "cached certificates" by renaming the trustedcerts.xml file (%APPDATA%\FileZilla\trustedcerts.xml) and allowing the FileZilla Client software to recreate it.
5. Updated the user's FileZilla Client software to the latest version.

At this point, I'm not sure what else to look at, and I'm hoping that someone can at least point me in the right direction. I'm leaning towards something on the user's network possibly causing the issue, but I want to try to get some evidence of that before I go "blaming" another IT Department. Any help you can provide would be greatly appreciated.

[botg]

Could there be a malicious firewall or virus scanner that is breaking TLS connections by issuing fake certificates?

[G_Hosa_Phat]

I can't check immediately, as I have to request permission to connect to the user's computer to check everything, but I'm looking into a couple of suggestions I've received that include the possibility that a recent update to the user's security software may be interfering with the certificate exchange. I'll be comparing the certificate details on the client machine against the certificate details on my machine (where I can connect without error) by pulling them up from the "lock" icon in the status bar. Since this issue just started happening and nothing else that I know of has changed, that seems to me to be the best explanation I can find so far.

[G_Hosa_Phat]

I connected in to my client's workstation and checked a few more things. I found that the client is using a domain-controlled installation of Webroot SecureAnywhere® Business Endpoint Protection software. They are still unable to connect, so this time I copied the logging information from the main FileZilla Client window:

Code: Select all

Status: Resolving address of ftp.company.com
Status: Connecting to XX.XX.XX.86:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Status: Server sent passive reply with unroutable address. Using server address instead.
Command:    MLSD
Response:   150 Transferring directory
Error:  Primary connection and data connection certificates don't match.
Error:  Transfer connection interrupted: ECONNABORTED - Connection aborted
Response:   226 Transfer completed
Error:  Failed to retrieve directory listing

Also, I compared the certificate details between his machine and mine. The Fingerprint (SHA-256) and Fingerprint (SHA-1) differ, and, more noticeably, so does the Certificate Issuer. On mine, it shows the correct issuer of PositiveSSL CA 2 (COMODO CA Limited), but on his it shows the issuer as FortiGate CA (Fortinet)

I had the user temporarily disable their Webroot protection (someone from his IT Department was luckily there to help us), and tried again. Unfortunately, the same problem occurred, and when I checked the certificate again, it still showed the same discrepancies when compared against the one listed on my computer.

Their IT guy also tried the connection from a fresh install of the FileZilla Client software on another PC on the same network. That connection resulted in the same error. I suggested the possibility of configuring the FileZilla Client software on a laptop connected to another network (like a cell phone's WiFi hotspot) to see if the problem persists, but they haven't had the chance to do that yet.

As an additional testing measure, I set up a new connection in my FileZilla Client where I explicitly specified the IP address from the user's connection log I posted above, just to be sure there wasn't anything different about the way I was connecting. I didn't get any errors, and my Certificate details dialog shows the same thing as it did before (other than the host being listed as the IP address instead of the DNS name). Here is the log from my most recent session:

Code: Select all

13:35:44    Status: Connecting to XX.XX.XX.86:21...
13:35:44    Status: Connection established, waiting for welcome message...
13:35:44    Status: Initializing TLS...
13:35:44    Status: Verifying certificate...
13:35:44    Status: TLS connection established.
13:35:45    Status: Logged in
13:35:45    Status: Retrieving directory listing...

[G_Hosa_Phat]

I just got a call back from the client informing me that his IT Department found the cause of the issue and have made changes internally to get his connection working. Here's a summary:

Over a year ago, our company changed the IP address of our FTP server. At that time, we sent out an e-mail "blast" to all of our clients and partners notifying them of this change. Apparently, however, this client's IT Department didn't get that memo because they didn't recognize the IP address and didn't have appropriate rules in their firewall to allow that traffic.

The fact that it has been working for over a year without error still stumps me a bit, but as long as it's working now, I'm going to let it go (for now).