Opened 2 years ago
Closed 2 years ago
Last modified 2 years ago
#12347 closed Bug report (invalid)
Update failures - filezilla-project.org is using a local CA, so no path to verification
|Reported by:||m27GUmtEKeVEla||Owned by:|
|Component version:||3.51.0||Operating system type:|
|Operating system version:||Windows 10.0.18362.1256|
When checking for updates in the client, I saw the update failing to connect. I grabbed the connection string from the "Show details" link and pasted it into a browser (Chrome for example). The link for me was https://update.filezilla-project.org/update.php?cpuid=sse%2Csse2%2Csse3%2Cssse3%2Csse4.1%2Csse4.2%2Cavx%2Cavx2%2Caes%2Cpclmulqdq%2Crdrnd%2Cbmi%2Cbmi2%2Cadx%2Clm&initial=1&manual=1&osarch=64&osversion=10.0&package=1&platform=x86_64-w64-mingw32&updated=0&version=3.51.0
This should generate a standard warning that pops up whenever certificates can't be validated. Looking at the certificate, the cert specified for update.filezilla-project.org seems good; however, it was issued by a private ca for filezilla-project.org with a private IP address of 10.6.92.6. This needs to be issued as a resolvable host (also: use FQDN, not IP).
New cert looks to have been applied around Dec 14.
Change History (4)
comment:1 by , 2 years ago
|Summary:||filezilla-project.org us using a local CA, so no path to verification → Update failures - filezilla-project.org is using a local CA, so no path to verification|
by , 2 years ago
|Attachment:||FileZilla cert bug.png added|
comment:2 by , 2 years ago
|Status:||new → closed|
BlueCoat proxies replacing certificate in this case. No action needed.
comment:3 by , 2 years ago
For security reasons, communication with the update server is authenticated by a custom CA trusted by FileZilla. It deliberately does not use the system trust store. Updates thus will fails if a malicious firewall tampers with TLS connections.
Screenshot of certificate details