My domain is: gis.fri.uniza.sk
I ran this command: sudo certbot certonly --standalone --preferred-challenges http -d gis.fri.uniza.sk --debug-challenges -v
It produced this output:
"Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: gis.fri.uniza.sk
Type: connection
Detail: 158.193.146.179: Fetching http://gis.fri.uniza.sk/.well-known/acme-challenge/0CkdXAiT5_x_qFCr3MTvvpv2Jy_jT6OiAKHbv6c3FV0: Timeout during connect (likely firewall problem)
Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.
Cleaning up challenges
Some challenges have failed."
My web server is a virtual machine
The operating system my web server runs on is: Debian 12
I can login to a root shell on my machine: no
The version of my client is: certbot 2.1.0
Before I press enter to continue (and a few seconds after... until the challenges are cleaned up) the link is accessible from the browser and a matching hash is shown. But Letsencrypt times out in spite of that. It is not a firewall issue, nothing runs on port 80 and it accepts any connection. For the last 2 years it was automatically updating without issues, but it started crashing today for some reason.
Not from my point of view.
Without anything running on a port, I'd expect a "connection refused" error returned by the server. However, I too am getting a timeout. So something is up. Something is blocking access to port 80.
1 Like
The following URLs should be accessible from the internet and return the value
mentioned:
URL:
http://gis.fri.uniza.sk/.well-known/acme-challenge/nUhb3t4wO96jEZiYyQNuXcYXkRgqf1sPq9wriGtmlYw
Expected value:
nUhb3t4wO96jEZiYyQNuXcYXkRgqf1sPq9wriGtmlYw.oEPBLSAL2Tnu1xDv6c3yLh0xdAF_ueWMFSleuCoRJAE
Press Enter to Continue
I am not pressing anything right now. This is proof that the --standalone created a temporary server and connected without issue, if I'm understanding it correctly.
Sure, if something is not blocking access to port 80 
However, I'm still not able to connect. Which makes sense, as mentioned earlier, I otherwise would have expected a "connection refused" error earlier. But even now with Certbot running, I'm getting a timeout.
1 Like
Partly true. Did you try a request from the public internet? Like wifi disabled on your mobile?
Because I timeout trying your domain from a US based server right now. If you still have that running it should connect and give some reply
curl -i -m8 http://gis.fri.uniza.sk
curl: (28) Connection timed out after 8001 milliseconds
2 Likes
Here's a site that tries connecting from many places around the world, if that helps in your testing:
3 Likes
The websites I use it on are the following:
https://gis.fri.uniza.sk:7980 (doesn't work because I tried to remove /etc/letsencrypt and start over)
https://gis.fri.uniza.sk/geoserver/ (still works because I generated PKCS12 file accessed via keystore)
But port 80 ? Why would it time out?
There is also possibility that Gorilla dotnet that broke into my system may be blocking it.
This is what I see when I log in:
Linux gis 6.8.12-8-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-8 (2025-01-24T12:32Z) x86_64
gorilla botnet is on the device ur not a cat go away
Last login: Thu May 1 15:18:17 2025 from 158.193.102.156
,met$$$$$gg. janovic3@gis
,g$$$$$$$$$$$$$$$P. ------------
,g$$P" """Y$$.". OS: Debian GNU/Linux 12 (bookworm) x86_64
,$$P' $$$. Host: PowerEdge M600 ',$$P ,ggs. $$b: Kernel: 6.8.12-8-pve
d$$' ,$P"' . $$$ Uptime: 3 hours, 33 mins $$P d$' , $$P Packages: 713 (dpkg) $$: $$. - ,d$$' Shell: bash 5.2.15 $$; Y$b._ _,d$P' Resolution: 1024x768 Y$$. ."Y$$$$P"' Terminal: /dev/pts/4 $$b "-._ CPU: Intel Xeon E5405 (8) @ 1.995GHz
Y$$ GPU: AMD ATI 0d:04.0 ES1000 Y$$. Memory: 1986MiB / 12288MiB
$$b. Y$$b.
"Y$b._ """
Beats me, firewall, missing NAT portmap, DDoS protection systems. Such things.
No, it doesn't.
Well, if that's the case, then a timeout when trying to get a certificate is the LEAST of your problems..
Getting a new certificate on an exploited machine is stupid anyway, as there's no way to make sure the generated private key stays, well, private. So you'd need to revoke the certificate once it was issued..
Please take your host offline IMMEDIATELY and fix the botnet issue. Which most likely requires a full wipe of the host and start over with just the necessary text based configuration files as backup from the exploited machine. Any binary cannot be trusted.
Keeping a exploited botnet host (knowingly) online makes you complicit in the DDoS of other hosts on the internet.
1 Like
I see, alright, I'll contact my providers, to do so. I already have necessary backups.
Could you please give me any sort of advice how to protect my self from this bot better in the future?
Oh, and if it is dangerous maybe deactivate the certificate for now?
That's (far) outside the scope of this Community.
If the host containing the private keys is exploited then yes, I'd recommend revoking the certificates.
1 Like