1

One of my clients has recently started getting the above-mentioned error message in the FileZilla Client software (on Windows 7) when connecting to my FTP server (WS_FTP Server by Ipswitch). Before getting into what I've done for troubleshooting so far, here are a few points about this issue:

  • 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.
  • I use the FileZilla Client software myself and am unable to reproduce the error connecting to the same server.
  • 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.
  • The WS_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 WS_FTP 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. Following instructions from several posts on the FileZilla Forums, 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.

I've cross-posted this information from the FileZilla Forums page, but because I'm aware the issue could potentially be the client software, something in the user's network or even something in my server, I wanted to widen the net a bit. 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.

UPDATE: I connected in to my client's workstation and checked the items suggested by @Martin Prikryl in the comments. 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:

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. Here is a screenshot of my Certificate Details dialog: My Certificate Details Dialog

And here's a screenshot of his Certificate Details dialog: Client Certificate Details Dialog

I've redacted the URLs in the images, but they all match up. Looking at the Fingerprint values and the details of the Certificate issuer block, however, there are obviously some discrepancies. 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.

Our SSL certificate IS a COMODO PositiveSSL certificate, so now I just need to determine what's causing his system/network to be picking the issuer up as Fortinet.

EDIT: On a whim, 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:

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...

UPDATE #2: 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). I'll post a troubleshooting summary as an answer later, but I've got to get back to work.

  • 2
    If you double-click the lock on FileZilla status bar, do you get the same info (fingerprints etc) on your machine as on the client's machine? – Martin Prikryl Nov 9 '17 at 19:48
  • I tried to look at all of that, but I don't remember at this point. I have to contact the client and request permission to remote into their machine to check for sure, but I'll be sure to look at that. Just as a point of clarification, I feel it important to reiterate that the issue just started recently and the SSL certificate on my server has not changed between its last successful connection and the failures they are now experiencing. Are you suggesting that the user's certificate "cache" somehow got corrupted between these two occasions? – G_Hosa_Phat Nov 9 '17 at 19:54
  • 1
    I do not think this has anything to do with any cache. It's rather that some security software acts as MITM, but affects either the control connection only or data connection only or does not generate the same certificate for them. – Martin Prikryl Nov 9 '17 at 19:55
  • That makes sense. So, possibly a recent update to the user's security software is causing a "misinterpretation" of the certificate during the TLS negotiation, which is then somehow causing the perceived discrepancy between the primary and data channel certificates. Of course, I don't know what security software the client is using, but I'll add that to my list of things to check the next time I reconnect to their machine. – G_Hosa_Phat Nov 9 '17 at 20:10
0

In my research of the "Primary connection and data connection certificates don't match" error message reported by the FileZilla Client software, most solutions seem to point to a misconfiguration of the FTP server. While this is certainly a valid troubleshooting "step", there are several additional steps to investigate - especially if the end user has been able to successfully connect before.

This specific error means that basic Internet connectivity has been established between the FileZilla Client software and the FTP server. The problem is not in getting connected to the FTP server but in the negotiation of the SSL/TLS encryption of the communication. The (release) FileZilla Client software will not allow a TLS connection to continue if there is any doubt about the validity of the SSL certificate.

The following troubleshooting steps should help to identify and/or resolve the cause of the error, or at least eliminate some possibilities:

CLIENT-SIDE TROUBLESHOOTING

  1. Verify the FTP client's connection settings, including:
    • Hostname/IP and port
    • SSL/TLS option(s)
    • FTP server login information (username/password)
    • Server type
    • Transfer mode (active/passive)
  2. Check/clear any cached certificate information on the client machine.
    • In the FileZilla Client software, this is done by deleting/renaming the XML file that stores these certificates (%APPDATA%\FileZilla\trustedcerts.xml)
  3. Make sure the FTP client software is up-to-date. It's possible that other changes (FTP server updates, network configuration changes, security software updates, etc.) may be causing a problem in the communication.
  4. If the FTP client is on a local network, try connecting from another computer on the same network. If this other computer is able to connect, the issue is specific to one (or more) computer(s).
  5. Try disabling any security software installed on the client machine. Some A/V or other Internet Security applications can act as a "man-in-the-middle" that can interfere with the communication between the FTP client and FTP server.
  6. If possible, try using another Internet connection to access the FTP server.
    • The "easiest" way that I've found to test this is to turn on my cell phone's WiFi hotspot and connect a laptop to that network.
  7. If the FTP client is behind a firewall, be sure that that firewall is not blocking or otherwise interfering with the FTP traffic. Depending on the firewall, this may mean opening ports on the firewall, whitelisting the FTP server IP address, or other configuration options.

IF YOU CONTROL THE FTP SERVER

Of course, depending on the FTP server software being used, there are a vast number of things that you may need/want to check. I'm just listing the "basics" here.

  1. Check the FTP server logs for any additional details about the failed connection.
  2. Verify that the SSL certificate installed on the FTP server hasn't expired and is still valid.
  3. Review the SSL/TLS configuration settings on the FTP server.
  4. Verify the public (and/or internal) DNS records and configuration pointing to the FTP server.
  5. Make sure the FTP server doesn't have the user blocked/blacklisted, either by username or IP address. This may also (possibly) include things like the user account requiring a password update/reset, or other internal security settings.

IF YOU DON'T CONTROL THE FTP SERVER

Contact the individual/company in charge of the FTP server. Provide them with the results of the Client-Side Troubleshooting to help the administrator(s) in troubleshooting their end of the connection.

  • NOTE: Because FileZilla is an open-source project, it is possible to get the source code and modify it so that the software ignores this potential danger. The explanation of what changes to make are on the FileZilla Forums. Please be aware, though, that, while I'm including this link, unless you are only using this software in a very controlled environment, I would not recommend taking this step.

Depending on the client's local environment, there may be other troubleshooting steps to take as well. Also, if I've missed something obvious in my steps here, please comment so I can add it in case anyone else runs across this issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.