Timeout during connect (likely firewall problem)

[Sangkwun]

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:

demo.lomin.ai

I ran this command:

certbot-auto certonly --manual

It produced this output:

Press Enter to Continue
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. demo.lomin.ai (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://demo.lomin.ai/.well-known/acme-challenge/EWbLNaAWwRZGM1UCqSvbIIxFFaoH09wPUEwVuYucCb0: Timeout during connect (likely firewall problem)

IMPORTANT NOTES:

• The following errors were reported by the server:

  Domain: demo.lomin.ai
  Type: connection
  Detail: Fetching
  http://demo.lomin.ai/.well-known/acme-challenge/EWbLNaAWwRZGM1UCqSvbIIxFFaoH09wPUEwVuYucCb0:
  Timeout during connect (likely firewall problem)

  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.

• Your account credentials have been saved in your Certbot
  configuration directory at /etc/letsencrypt. You should make a
  secure backup of this folder now. This configuration directory will
  also contain certificates and private keys obtained by Certbot so
  making regular backups of this folder is ideal.

---

My web server is (include version):

nginx version: nginx/1.13.12

The operating system my web server runs on is (include version):

PRETTY_NAME=“Debian GNU/Linux 9 (stretch)”
NAME=“Debian GNU/Linux”
VERSION_ID=“9”
VERSION=“9 (stretch)”
ID=debian

My hosting provider, if applicable, is:

AWS route 53.

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

[Sangkwun]

Hello all!
I’m using Docker env with exposed 80, 443 port.
And I tested standalone and nginx plugin command for certbot.
But all of them doesn’t work for me.
So I tried with --manual option for debug.
As i understand certbot wants me to make url like “http://demo.lomin.ai/.well-known/acme-challenge/HHv-e7A6inc_lGwWqyfrzBfEZRm2LlLHWsIbpEDaEEw” to response ‘HHv-e7A6inc_lGwWqyfrzBfEZRm2LlLHWsIbpEDaEEw.9QWlxiDYoLlCDmfW3iNIOr5c9QYGGyBwfEZdCELrlKo’.
So I make the url with the key even I can access by myself.
But the http-01 challenge is not possible to me…
Anybody have idea to solve it?

[JuergenAuer]

Hi @Sangkwun

@Sangkwun

demo.lomin.ai

checked your domain online there are only timeouts (via demo.lomin.ai - Make your website better - DNS, redirects, mixed content, certificates ):

---

Domainname	Http-Status	redirect	Sec.	G
• http://demo.lomin.ai/
147.46.238.11	-14		10.023	T
Timeout - The operation has timed out
• https://demo.lomin.ai/
147.46.238.11	-14		10.030	T
Timeout - The operation has timed out
• http://demo.lomin.ai/.well-known/acme-challenge/check-your-website-dot-server-daten-dot-de
147.46.238.11	-14		10.027	T
Timeout - The operation has timed out

---

So it's impossible to Letsencrypt to check your file. Your site is invisible.

[Sangkwun]

Uhm.. Thanks for letting me to know clue for error.

I can access webpage via browser.
what's the difference between the test and normal access?

---

Below is my nginx part for 80port.

server {
listen 80;
listen [::]:80;
server_name demo.lomin.ai;

location /.well-known {
    root /app/static;
}

location / {
    #return 200;
    return 301 https://$server_name$request_uri;
}

}

[jmorahan]

I can’t access your site in a browser either. Are you accessing it from the same network that it’s hosted on? Maybe your firewall is blocking external traffic?

[JuergenAuer]

@Sangkwun

I can access webpage via browser.

With my browser I have the same result. But browsers are sometimes terrible to check such things. Browsers save redirects and Strict-Transport-Security settings, so online tools are better. They start always fresh.

[Sangkwun]

My ufw status result is like below.
uhm is it possible to cause of router setting?

Status: active

To                         Action      From
--                         ------      ----
Nginx Full                 ALLOW       Anywhere
22/tcp                     ALLOW       Anywhere
22                         ALLOW       Anywhere
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere
Nginx Full (v6)            ALLOW       Anywhere (v6)
22/tcp (v6)                ALLOW       Anywhere (v6)
22 (v6)                    ALLOW       Anywhere (v6)
80 (v6)                    ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)

[Sangkwun]

Oh as you said I can’t access the site via my smartphone!
I just accessed from same network from the server.
Is there any thing to solve it?

[jmorahan]

The ufw settings look fine. Yes, it could possibly be a router setting. Is the router configured to forward those ports to the web server? You need at least port 80 for validation and port 443 to actually serve HTTPS.

[Sangkwun]

I find the reason of problem…
I’m running server in university but the ports are not opened…
Thank you for all of you guys.
I need to open these ports first.