Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I ran this command: sudo certbot certonly --webroot -w /var/www/letsencrypt -d sasc.beberibe.ce.gov.br
It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Requesting a certificate for sasc.beberibe.ce.gov.br
Performing the following challenges:
http-01 challenge for sasc.beberibe.ce.gov.br
Using the webroot path /var/www/letsencrypt for all unmatched domains.
Waiting for verification...
Challenge failed for domain sasc.beberibe.ce.gov.br
http-01 challenge for sasc.beberibe.ce.gov.br
Cleaning up challenges
Some challenges have failed.
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
My web server is (include version): nginx version: nginx/1.18.0
The operating system my web server runs on is (include version): Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
My hosting provider, if applicable, is:
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): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.12.0
I have been using this certification method for a while, however, after I implemented automatic certification, this method stopped working correctly, now I need to return the systems with their certifications.
There is no webserver listening on port 443 (I'm getting a connection refused) and port 80 seems to timeout entirely, probably a firewall thing as also mentioned by the error message already.
Please make sure your website is up and running, including port 80 (a redirect to HTTPS is fine) and try again.
I am currently serving using Nginx configured on port 80. When I use the debug command, which stops the application when generating the file, the confirmation file is generated correctly, I have access to it through the browser external to the server and also access via "curl", but let's encrypt does not find this file. I have already checked the firewall and everything is ok, it was possible that the firewall blocked access to let's encrypt.
Have you also tried from outside your own network? I.e., using your phone without WiFi? Or VPN? Because your website is still NOT reachable from the global internet.
See e.g. Let's Debug that also tries to connect itself.
Then there must be something else blocking global access to your site. Perhaps at the ISP level, perhaps a missing NAT portmap, I don't know.
Please make sure Let's Debug or other worldwide connection testing sites can connect to your site before trying again with Let's Encrypt.
Based on the information you gave me, I did some tests here. I used the command “sudo certbot certonly --webroot -w /var/www/letsencrypt -d sasc.beberibe.ce.gov.br -debug-challenges”, when the command runs the file is created correctly, in another terminal I list the existing files in the directory, and the file is there correctly created. In the same terminal that I checked the existence of the file I use the command “curl -i http://sasc.beberibe.ce.gov.br/.well-known/acme-challenge/[arquivo]“ and I get the return:
“HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Wed, 09 Apr 2025 17:20:56 GMT
Content-Type: text/plain
Content-Length: 87
Last-Modified: Wed, 09 Apr 2025 17:08:23 GMT
Connection: keep-alive
ETag: "67f6a987-57"
This indicates that the file is being served correctly on the server. We should note that this test was performed on the server in question. When we requested the files via the browser on a machine that is on the same network as the server, we received a successful response. The problem occurs when we request the files on an external network. In my case, I used the telephone company's network. Another test was performed by running the command “tracert sasc.beberibe.ce.gov.br” on the machine that was using a network external to the server. We observed a delay in displaying the routes and hops with errors, possibly due to timeouts. Contact your internet provider. They want to know who is requesting the files, which in this case is Let's Encrypt. I believe they want to identify the requester, which could be the IP address.