# Certbot failed to authenticate some domains (authenticator: standalone) **URL:** \ **Category:** Help\ **Created:** [April 30, 2024, 11:50am UTC](https://community.letsencrypt.org/t/certbot-failed-to-authenticate-some-domains-authenticator-standalone/217465 "2024-04-30T11:50:19Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![rajib.saiful84](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rajib.saiful84/32/79526_2.png) [@rajib.saiful84](https://community.letsencrypt.org/u/rajib.saiful84)\ **Post date:** [April 30, 2024, 11:50am UTC](https://community.letsencrypt.org/t/certbot-failed-to-authenticate-some-domains-authenticator-standalone/217465/1 "2024-04-30T11:50:19Z")
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](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: [soc.asa-international.com](http://soc.asa-international.com) I ran this command: certbot certonly --standalone -d [soc.asa-international.com](http://soc.asa-international.com) -v It produced this output: Challenge failed for domain [soc.asa-international.com](http://soc.asa-international.com) http-01 challenge for [soc.asa-international.com](http://soc.asa-international.com) Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems: Domain: [soc.asa-international.com](http://soc.asa-international.com) Type: connection Detail: 115.127.99.12: Fetching [http://soc.asa-international.com/.well-known/acme-challenge/Lm4\_9GWkMHvgiHm4WIFo3MHC6NAT5JacSLg6krFeX3A:](http://soc.asa-international.com/.well-known/acme-challenge/Lm4_9GWkMHvgiHm4WIFo3MHC6NAT5JacSLg6krFeX3A:) 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. 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): ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [April 30, 2024, 2:04pm UTC](https://community.letsencrypt.org/t/certbot-failed-to-authenticate-some-domains-authenticator-standalone/217465/2 "2024-04-30T14:04:15Z")
Welcome @rajib.saiful84 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 ```nohighlight certbot certonly --standalone --dry-run --debug-challenges -v -d soc.asa-international.com ``` 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. ```nohighlight ACME client standalone challenge solver ``` ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [April 30, 2024, 2:33pm UTC](https://community.letsencrypt.org/t/certbot-failed-to-authenticate-some-domains-authenticator-standalone/217465/3 "2024-04-30T14:33:21Z")
> [@MikeMcQ](#): > > The --standalone method is difficult to debug because you need to keep Certbot running to test connection from the public internet. Not really. 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. ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [April 30, 2024, 2:45pm UTC](https://community.letsencrypt.org/t/certbot-failed-to-authenticate-some-domains-authenticator-standalone/217465/4 "2024-04-30T14:45:53Z")
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. Fully agree more info from them would be helpful. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [April 30, 2024, 2:51pm UTC](https://community.letsencrypt.org/t/certbot-failed-to-authenticate-some-domains-authenticator-standalone/217465/5 "2024-04-30T14:51:44Z")
> [@MikeMcQ](#): > > I'd be curious to know what method they used to get the cert for `api` subdomain the last time. Something must be different in their configuration. I now see Apache replying to HTTP(port 80) requests so it can't be an ISP block. 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](https://crt.sh/?id=12574483150) which could also be used I guess, so not sure why OP requires these LE certs to begin with. ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [April 30, 2024, 2:53pm UTC](https://community.letsencrypt.org/t/certbot-failed-to-authenticate-some-domains-authenticator-standalone/217465/6 "2024-04-30T14:53:00Z")
Oh my good grief. Got my threads mixed up. Sorry. I have a jackhammer working outside my office. I will blame that 🙂 ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [May 30, 2024, 2:53pm UTC](https://community.letsencrypt.org/t/certbot-failed-to-authenticate-some-domains-authenticator-standalone/217465/7 "2024-05-30T14:53:37Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.