Filezilla Could not connect to host

I'm running FileZilla 1.7.3 on a Windows Server 2022. I setup Let's Encrypt through Filezilla several months ago, and it's been running and updating the certificate successfully until recently. I have not updated Filezilla, or changed anything on the server - although normal Windows Updates, etc are happening automatically.

I'm not sure how long Filezilla has been failing to renew the certificate - the log file is only retained a couple of days. Based on the certificate Expiration date, I'm guessing 6 days ago.

From reading other topics, I thought it might be a blocked IP, but

C:> ping
Pinging [] with 32 bytes of data:
Reply from bytes=32 time=13ms TTL=55
Reply from bytes=32 time=13ms TTL=55
Reply from bytes=32 time=13ms TTL=55
Reply from bytes=32 time=13ms TTL=55
Ping statistics for
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 13ms, Average = 13ms

C:>curl -vvv

  • Trying
  • Connected to ( port 443
  • schannel: disabled automatic use of client certificate
  • ALPN: curl offers http/1.1
  • ALPN: server accepted http/1.1
  • using HTTP/1.1

GET /directory HTTP/1.1
User-Agent: curl/8.4.0
Accept: /

My domain is:

I ran this command: I'm not sure of the command - Filezilla has an automated process for requesting a certificate renewal

It produced this output:
<08-12-2023 09:15:45> ACME Daemon [Status] Next certificate to be renewed is registered with the account [], for the domains [].
<08-12-2023 09:15:45> ACME Daemon [Status] Starting renewal of certificate NOW.
<08-12-2023 09:15:45> ACME [Status] Listening on
<08-12-2023 09:15:45> ACME [Status] Listening on [::]:80.
<08-12-2023 09:15:46> ACME [Error] Error: HTTP Internal error: ECONNABORTED - Connection aborted. Could not connect to host
<08-12-2023 09:15:46> ACME Daemon [Error] Finished renewal of certificate for the domains [], registered with the account []. FAILED.
<08-12-2023 09:15:46> ACME Daemon [Error] Retrying in 300 seconds.
<08-12-2023 09:15:46> ACME Daemon [Status] Next certificate to be renewed is registered with the account [], for the domains [].
<08-12-2023 09:15:46> ACME Daemon [Status] It will be renewed on the date [Thu, 07 Dec 2023 22:20:46 GMT].

My web server is (include version): Filezilla Server 1.7.3 - internal webserver

The operating system my web server runs on is (include version): Windows Server 2022 Standard - up-to-date with Windows Updates. Running in a VMWare 8.0 VM

My hosting provider, if applicable, is: Inhouse

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Yes - Filezilla 1.7.3

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Filezilla does not use Certbot, as far as I can see.

Hello @tt-rick, welcome to the Let's Encrypt community. :slightly_smiling_face:

Port 80 is being filtered. Best Practice - Keep Port 80 Open

$ nmap -Pn -p80,443
Starting Nmap 7.80 ( ) at 2023-12-08 01:11 UTC
Nmap scan report for (
Host is up (0.19s latency).
rDNS record for

80/tcp  filtered http
443/tcp open     https

Nmap done: 1 IP address (1 host up) scanned in 3.81 seconds

Also using the online tool Let's Debug yields these results

ERROR has an A (IPv4) record ( but a request to this address over port 80 did not succeed. Your web server must have at least one working IPv4 or IPv6 address.
A timeout was experienced while communicating with Get "": context deadline exceeded

@0ms: Making a request to (using initial IP
@0ms: Dialing
@10001ms: Experienced error: context deadline exceeded
A test authorization for to the Let's Encrypt staging service has revealed issues that may prevent any certificate for this domain being issued. Fetching Timeout during connect (likely firewall problem)
1 Like

Out of interest what AV/malware protection are you running? Things like ESET, clamwin etc.

1 Like

Hi Bruce5051,

Thanks for this.

Port 80 is only used by Filezilla for Let's Encrypt certificate renewal. I know Filezilla opens and closes port 80 on it's internal website only while it is doing it's Let's Encrypt renewal - and this is indicated by the following entries in the log

<08-12-2023 09:15:45> ACME [Status] Listening on
<08-12-2023 09:15:45> ACME [Status] Listening on [::]:80.

I can't see anyway to control this process in Filezilla.
The firewalls (on router and Windows server) have port 80 open all the time.

netstat on the server shows nothing is using port 80. I haven't been able to "fluke" running netstat while Filezilla has port 80 open.

Note port 443 is forwarded to a different device. I assume this is not important

1 Like

Hi webprofusion,

Sophos Endpoint Agent. The Sophos log doesn't list anything at the times Filezilla is trying to renew the Let's Encrypt certificate

Might be important. The Let's Encrypt client must make an outbound connection on port 443 to the LE API. Is that available? Because that is what is failing.


Hi MikeMcQ,

I should have said incoming port 443 is forwarded by the router to a different device.

I can browse from the server to internet sites using https, and the curl command on the server to test (curl -vvv is successful

It could have "started" failing the instant after you got your original cert. Between then and 6 days ago most likely nothing would have been tried since your cert was "fresh enough" until just 6 days ago.

Are you sure something is not firewalling port 80? Because filezilla can open the port 80 but if something else between it and the internet is blocking it that would still fail.

It is difficult to test port 80 if it is only open briefly during cert request.

But, I would focus on the one error we actually see which is the outbound connection failure. I do not have ideas on how that would fail while a sample curl works. Possibly and app-based firewall or some other kind of routing issue with ports or what-not from the filezilla client. Maybe the VM not having the port connected to its host o/s or similar. Did the sample curl run from the same environ as the filezilla client?


push up log level of filezilla to 5 (from debug) and try it again, and post log here


Thanks @orangepizza,

upped the log level to 5 - Debug:

2023-12-08T03:51:19.715Z == [ACME Daemon] Next certificate to be renewed is registered with the account [], for the domains [].
2023-12-08T03:51:19.715Z == [ACME Daemon] Starting renewal of certificate NOW.
2023-12-08T03:51:19.716Z == [ACME] Listening on
2023-12-08T03:51:19.716Z == [ACME] Listening on [::]:80.
2023-12-08T03:51:19.716Z DD [ACME] >>> Entering do_get_certificate
2023-12-08T03:51:19.716Z DD [ACME] >>> Entering do_get_account
2023-12-08T03:51:19.716Z DI [ACME] Getting directory...
2023-12-08T03:51:19.716Z DD [ACME/HTTP Client] Connecting to
2023-12-08T03:51:19.716Z DD [ACME] <<< Leaving do_get_account
2023-12-08T03:51:19.716Z DD [ACME] <<< Leaving do_get_certificate
2023-12-08T03:51:20.213Z DD [ACME/HTTP Client] Certificate is trusted: no
2023-12-08T03:51:20.213Z DW [ACME/HTTP Client] ECONNABORTED - Connection aborted. Could not connect to host
2023-12-08T03:51:20.213Z !! [ACME] Error: HTTP Internal error: ECONNABORTED - Connection aborted. Could not connect to host
2023-12-08T03:51:20.213Z DD [ACME] Destroying.
2023-12-08T03:51:20.213Z DD [ACME] Stopping listeners.
2023-12-08T03:51:20.213Z DD [ACME] Destroying sessions.
2023-12-08T03:51:20.213Z !! [ACME Daemon] Finished renewal of certificate for the domains [], registered with the account []. FAILED.
2023-12-08T03:51:20.213Z !! [ACME Daemon] Retrying in 300 seconds.
2023-12-08T03:51:20.216Z == [ACME Daemon] Next certificate to be renewed is registered with the account [], for the domains [].
2023-12-08T03:51:20.216Z == [ACME Daemon] It will be renewed on the date [Fri, 08 Dec 2023 03:56:20 GMT].
2023-12-08T03:51:20.216Z DW [ACME/HTTP Client] 105. Channel closed with error from source 0.

The " [ACME/HTTP Client] Certificate is trusted: no" looks suspicious.

When I use Chrome to go to on the server, I can see the certificate is using "ISRG Root X1" as it's trusted root certificate. I wonder if Filezilla uses the system trusted Root certificates...


Maybe not, the detailed log clearly shows it does not trust the certificate. But it could also be an anti virus like already stated above trying to intercept all outbound HTTPS connections and perform a MitM attack with a self-signed cert.


Hi Osiris,

Thanks for this.

I had already checked the system trust store (MMC > local computer certificates > Trusted Root Certification Authority store > certificates). Checked again that the ISRG Root X1 certificate was there and confirmed that it appears to be up-to-date.
Temporarily disabled the anti-virus in case it was intercepting the https - not sure why it would intercept some https (from Filezilla) but not others (browser) when both are going to the same site.
Tried to renew the certificate again, still no joy.

While checking this I noticed that the server had not rebooted for a couple of months, so I scheduled a reboot of the server over the weekend. And have come in this morning to see the certificate has successfully renewed!!! Mark it up to another MS glitch :frowning:

Anyhow, thanks for your confirmation that it was an issue with trusting the certificate. It stopped me going off on a tangent.


Glad you got it fixed but it's clearly a Filezilla glitch, attributing the glitch to Microsoft is perhaps more fun but inaccurate/unfounded. FileZilla implement their own TLS layer:


FileZilla Server uses libfilezilla, but libfilezilla is set up to use the system trust store, which is cached at FileZilla Server service's startup.

Restarting the FileZilla Server Service might have thus been enough to have it see the updated trust store.

I've however reported the fact to the other members of the team, so we can decide on a better course of action for the future.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.