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.
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.
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): yes
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):
The --standalone method is difficult to debug because you need to keep Certbot running to test connection from the public internet. If possible, you may try using --webroot method instead and use your existing web server to handle the HTTP Challenges on port 80.
But, if you want to keep --standalone a way to test this is to use these command options
This command will show you the challenge URL to try from the public internet and the proper response. After showing you this it will say "Press Enter to Continue". DO NOT PRESS ENTER.
Leave it paused like that and use a different device to test connection. You can use a mobile phone with wifi disabled to use your carrier's network.
You do not have to use the full URL. Just try http://soc.asa-international.com
If the connection works this shorter URL should see a response like below. Repeat this test while you modify your comms setup until it works.
If no firewall is blocking the incoming connection and there is no service (webserver/Certbot standalone authenticator), many if not all *nix OS will return an ICMP reply with the "Port unreachable error" code set or a RST flag reply, leading to a "connection refused" error.
A timeout is almost always the result of some kind of firewall block or a missing NAT portmap.
Unfortunately @rajib.saiful84 failed to answer some of the questions of the questionnaire, but from the IP address behind soc.asa-international.com (115.127.99.12), the WHOIS info suggests it's hosted at "BRACNet Limited" which seems to be a "internet connection for home users, businesses, and enterprises [provider]". Thus an ISP blocking incoming port 80 is also certainly an option I believe.
While all fair points but I think it is easier to explain a process by which they can see it is something on their end that is failing and a way to test changes.
I don't see an api subdomain on crt.sh nor does that subdomain resolve. I do however see an hr subdomain which has a different IP address (ending in 10 instead of 12) and has LiteSpeed listening.
I also see an Entrust wildcard (pre)certificate which could also be used I guess, so not sure why OP requires these LE certs to begin with.
