2023-07-26 17:06:34,978:DEBUG:acme.client:Sending POST request to https://acme-v02.api.letsencrypt.org/acme/authz-v3/249134282317:
2023-07-26 17:06:35,236:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "POST /acme/authz-v3/249134282317 HTTP/1.1" 200 1027
2023-07-26 17:06:35,236:DEBUG:acme.client:Received response:
Date: Wed, 26 Jul 2023 10:35:48 GMT
Cache-Control: public, max-age=0, no-cache
"detail": "220.127.116.11: Fetching http://www.dtm.gov.mm/.well-known/acme-challenge/3pflhrMf6EMUyQZTCjz9B9Ix3GPR_uy74GMrTG1QvNU: Connection reset by peer",
2023-07-26 17:06:35,236:DEBUG:acme.client:Storing nonce: 327CT4vEKs23O7XSfnSYNf9IFYw-hFFnWCz_HuTBebn0LWk
2023-07-26 17:06:35,237:INFO:certbot._internal.auth_handler:Challenge failed for domain www.dtm.gov.mm
2023-07-26 17:06:35,237:INFO:certbot._internal.auth_handler:http-01 challenge for www.dtm.gov.mm
2023-07-26 17:06:35,237:DEBUG:certbot._internal.display.obj:Notifying user:
Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Detail: 18.104.22.168: Fetching http://www.dtm.gov.mm/.well-known/acme-challenge/3pflhrMf6EMUyQZTCjz9B9Ix3GPR_uy74GMrTG1QvNU: Connection reset by peer
Hint: The Certificate Authority failed to verify the manually created challenge files. Ensure that you created these in the correct location.
Please kindly check my server IP was blocked?
When you opened this thread in the Help section, you should have been provided with a questionnaire. Maybe you didn't get it somehow (which is weird), or you've decided to delete it. In any case, all the answers to this questionnaire are required:
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.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you're using Certbot):
You are connecting to the Let's Encrypt servers successfully. This means you are not blocked by Let's Encrypt
But, the Let's Encrypt servers are not able to connect to you. You are blocking Let's Encrypt with a "reset by peer" error from your system.
I also failed to connect with a "reset by peer" error connecting to your "home" page using HTTP. But, after one reset failure subsequent requests worked. I see an Apache server (v2.4.37) running on CentOS (also using php 7.2 and drupal 7).
But, if I waited 5 minutes after the last successful request I again received a "reset by peer" error followed by more successful requests (see below).
These "reset by peer" errors are preventing you from satisfying the Let's Encrypt HTTP Challenge but also might be interfering with others using your website.
We have seen this pattern multiple times over the last several months but only with sites hosted on GoDaddy. Is your site on a service owned by them?
Your best option is to find why these "reset" errors happen and fix them. But, other options are:
- Use the Let's Encrypt DNS Challenge.
- Try a different free ACME Certificate Authority (CA) (maybe Google or ZeroSSL)
- Purchase a certificate which uses a different way to verify your domain name
From my own test server:
Wed Jul 26 13:52:15 UTC 2023
curl -I http://www.dtm.gov.mm
curl: (56) Recv failure: Connection reset by peer
curl -I http://www.dtm.gov.mm
HTTP/1.1 200 OK
Date: Wed, 26 Jul 2023 13:53:08 GMT
Server: Apache/2.4.37 (centos) OpenSSL/1.1.1k
X-Generator: Drupal 7 (http://drupal.org)
(other headers omitted)
If I check the whois of the IP address, it seems to be owned by "Cyber Security Department" / "Dept. of Information Technology & Cyber Security" of Myanmar. Soooooo, "self hosted"?
This might be due to some firewall trying to block spammers by blocking the first connection attempt, @mgkphyo might want to ask their IT department for more information regarding this behaviour.
Agree. And it would be wonderful if they find the firewall that is doing this and tell us. I think it is likely a similar firewall or device at these other sites and this would give us better info to help them.
I will check with datacenter IT department for this case. Thank you and appreciate your support.
I've checked with datacenter IT department and they found out because of the DDOS server blocked it. Now, it's solved.
Thank you and appreciate your support.
Can you share any more details of this DDOS server?
Like its brand, model, software system and/or version?
We have seen an increasing number of similar problems in last few months. It's possible you are the first to have identified the exact cause. It would be great if we knew more details to share with future people.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.