Filezilla issue after update

[boco]

As botg already told, you should show then the link to the RFC

https://tools.ietf.org/html/rfc5246#page-48

and ask them to fix their certificate chain. Being server administrators, they should know how to read and interpret internet standards documents, and follow them.

[halsil]

You have misunderstood my point.

FileZilla is quite right to insist on this if that is the standard, but it cannot be introduced without forewarning so that users and servers have time to react.

[FlyingWay]

Thanks for NameCheap, They explain it in this link


- How to set up FileZilla ?
Once you’ve downloaded and installed FileZilla, launch the program.
Navigate to the File tab > Site Manager menu:

Code: Select all

https://www.namecheap.com/support/knowledgebase/article.aspx/1279/205/how-to-setup-filezilla

[zedsta]

Workaround: roll back to previous version of FileZilla 3.19.0 - works a treat!

[botg]

Downgrading is not a supported user-case.

[Russ]

Yep, the fix here was to downgrade to version 3.19. You can find it in your downloads folder.

Whilst I agree with getting hosts to send the correct certificates, this was not the way to go about it. A better way would have been to pop up a warning saying 'hey, this will be disabled in a future version because of danger, or you can disable it now if you like. Please tell your host asap so you don't lose access in the future.'

Instead we had to search Google for the error message, and find this forum thread to even begin to work out what was going on.

My host ukhost4u.com is brilliant, and have now sorted the certificates, but in the meantime we were unable to access our FTP details without re-downgrading the software.

[botg]

There is actually code in FileZilla to sort the certificate chain, though it's not having any effect due to a bug in GnuTLS.

The unfortunate result is that broken servers are broken.

[botg]

https://ftptest.net/ has been updated to now also detect malformed certificate chains.

[husnain2010]

I have solved by switching from "FTP - File Transfer Protocol" to "SFTP - SSH File Transfer protocol" in the site Manager.

[boco]

You fixed nought. You're just avoiding the issue by using a completely different protocol and service.

[maried]

Yep, the fix here was to downgrade to version 3.19. You can find it in your downloads folder.

Whilst I agree with getting hosts to send the correct certificates, this was not the way to go about it. A better way would have been to pop up a warning saying 'hey, this will be disabled in a future version because of danger, or you can disable it now if you like. Please tell your host asap so you don't lose access in the future.'

Instead we had to search Google for the error message, and find this forum thread to even begin to work out what was going on.

I lost access to my regular FTP sites after upgrading yesterday. Having no idea what was wrong, I've spent 90 minutes so far with the Help desk today. Finally I found this forum, and discovered that FileZilla deliberately created a problem.

We're a big organization, and I have no idea when, if ever, our server certificates will be fixed. I have no alternative but to download to the previous version and never upgrade my FZ again (which formerly I've done every single time), or to stop using FZ altogether.

I have updated Site Manager based on the article above, and can get it to work for one site but not another. My Quickconnect fails altogether, so the new sw forces me to go through Site Mgr now. I liked FZ because of its ease of use. It's not easy anymore.

[botg]

We're a big organization, and I have no idea when, if ever, our server certificates will be fixed.

The bigger the faster it can get fixed. The amount of manpower big organizations have available makes this trivial.

Finally I found this forum, and discovered that FileZilla deliberately created a problem.

There is actually code in FileZilla to sort the certificate chain, though it's not having any effect due to a bug in GnuTLS.

The unfortunate result is that broken servers are broken.

[maried]

Corporate IT declined to fix it:
> Can you try to use regular Windows Explorer instead. I think the latest version of FileZilla has problems of this sort.....
Thank you

FYI, these aren't dedicated FTP sites. My company spins off temporary FTP sites on employee demand to facilitate large external file transfers. Most of these sites vanish in 2 weeks. Not sure if that means they need to fix the code for every single one?

Anyway, thanks for your help.

[botg]

That's not a sound advice corporate IT is giving you. Windows Explorer only supports insecure plaintext FTP.

It's likely that all their temporary FTP sites have the same problem and if they don't fix it, future ones will have the same problem.

[pwaara]

The new version of FileZilla is more strict about certificate chain verification and now rejects such malformed chains.

I spoke to my hosting and only way around it at the mo is to use the plain FTP as encryption

I know another way that doesn't compromise on security: It's your hosting provider fixing the server configuration so that it presents a well-formed chain. For most servers it's a dead trivial task, only a few lines in a text file need to be swapped around.

For those of you like me who manage their own servers, but didn't know where to fix this issue, here is the fix on a Centos 6.8 system. For ftp the certificate chain is located in /var/cpanel/ssl/ftp/pure-ftpd.pem. Putting the certificates in the correct order in this file and restarting the ftpd fixes the issue. You will also need to fix similar files in the cpanel, exim, and dovecot directories as well. I found the tool at https://www.digicert.com/help/ to be helpful in debugging the problem, though this only looks at the mycpanel.pem; however, it did help me get the order straight.

Hopefully, this will help you fix your issue faster than it took me today.