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. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is: www.addressforall.org
I ran this command: certbot certonly -v --debug-challenges --standalone <<list of 38 domains>>
It produced this output:
Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: addressforall.com
Type: connection
Detail: During secondary validation: 165.227.5.135: Fetching http://addressforall.com/.well-known/acme-challenge/W6GqneA3ckAX7eUk7CsWB8mjMJJgMzU4GUmJxtMOO9o: Timeout during connect (likely firewall problem)
after some test
An unexpected error occurred:
Service busy; retry later.
My web server is (include version):
The operating system my web server runs on is (include version):
Distributor ID: Ubuntu
Description: Ubuntu 24.04.3 LTS
Release: 24.04
Codename: noble
My hosting provider, if applicable, is: DigitalOcean
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):
root@addressforall:~/CERT# certbot --version
certbot 5.2.2
First, the --standalone option requires exclusive use of port 80. Not just for the initial cert but for every renewal. You note 38 domains in your cert. None of those domains will be able to use that port during each renewal. You will need to use a --pre-hook / --post-hook top stop/start them or some other method.
The --standalone option is a poor choice if those domains are web servers, for example. The time to setup and debug a different option is now rather than later. Let us know more about what you plan to use this cert and we can give better guidance.
I'll also mention that 38 domains in one cert can be tricky to manage over time. Using a cert for each service (like an nginx server block or an Apache VirtualHost) is usually easier.
As to this problem ... Let's Encrypt validates your domain from (currently) 5 different centers around the world. The primary center worked but two or more of the secondary centers were blocked. This is most likely something at your location blocking by geographic region. Or, perhaps certain IP ranges that allow the LE Primary center but not some secondaries. Or, possibly something blocking after seeing a certain volume of requests from specific origins.
Debugging the --standalone option is more difficult than with other options. And, debugging secondary failures for --standalone is even more difficult still. The first step is for you to vigorously review your setup for any kind of firewall or comms config affecting certain IP or origins.
If you can't find anything let us know and we can provide further debug steps. Also let us know if you plan to stay with --standalone after my comments above. Debugging that is very different than any other method.
3 Likes
Hello,
I have stoped the web server before any command. There is no firewall blocks the port 80 or 443.
The site certificate have been updated about 4 years without problem. No changes in secure configuration. Only the linux have been updated and upgraded. But no changes from dezember 2025.
If there any debug command, please send to me
Thanks
Carlos
Does that nginx server handle all those domains?
Because it is easier to test connections to that rather than --standalone.
Interestingly, I tested connections from my own test server running in AWS US East Coast. Two of your domains fail an HTTP (port 80) connection with a timeout: addressforall.com and afa.codes. Yet, a number of other tools connect just fine including the LE Primary center (only the secondary LE requests fail).
Why is that significant? Because all LE secondary centers are also AWS based. Sometimes people block large ranges of IP from providers like that. From my AWS server these requests to your "home" page fail (as do test requests similar to HTTP challenges)
curl -i http://addressforall.com/
curl: (28) Failed to connect to addressforall.com port 80 after 134938 ms:
Connection timed out
curl -i -m5 http://afa.codes
curl: (28) Connection timed out after 5001 milliseconds
Are you sure there hasn't been any changes anywhere regarding such connections? Not even in your DO setup or its settings? Maybe something like "bot" protection or DDoS protection or something like that?
It could have been a change since Dec31 when you got your last cert for these names.
4 Likes