Certbot: Always Times Out (truenas:nextcloud)

Help
1

I have forwarded ports, simplified domain registries down to one, and I have checked my nextcloud conf and conf/conf.php for domains. I have tried so many times now that it won't let me anymore, and I do not know where to go from here. I might give up an do everything unsecured at this point.

My domain is: Microtract.xyz

I ran this command: certbot --nginx -d microtract.xyz

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for microtract.xyz

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
  Domain: microtract.xyz
  Type:   connection
  Detail: Fetching http://microtract.xyz/.well-known/acme-challenge/_e--RcWB0uInVy5sqBNroPsIKW8keOlWdKyl3zqbw0I: Timeout during connect (likely firewall problem)

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessibl

My web server is (include version): nginx/1.20.2

The operating system my web server runs on is (include version): Freebsd 12.2 (jail to truenas core 12)

My hosting provider, if applicable, is: N/A

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): 1.22.0

1 Like
2

Hi @microtract and welcome to the LE community forum :slight_smile:

LE is not the only one that gets timed out:
Let's Debug (letsdebug.net)

curl -Ii microtract.xyz
curl: (56) Recv failure: Connection reset by peer

You will need a working HTTP site before you can secure it (via HTTP authentication).

3 Likes
3

I have no idea how to get it to stop redirecting to https. I am going through the dashboard on nextcloud because I do not understand where to find it in the configuration files.

1 Like
4

You are not redirecting from http to https. Well, maybe you are but no one can connect using http right now to find out. You need to fix that first. The good thing is that connections using https work although return an invalid cert (one from TrueNAS Nextcloud). The faulty cert will not prevent Let's Encrypt from issuing a new one so don't worry about that now.

Review what you do correct for port 443 and do the same for port 80

Update: Oh, and add --test-cert to command to use the LE test system. Will not block you out as easily

Try these:

curl -I http://microtract.xyz

curl: (28) Failed to connect to microtract.xyz port 80: Connection timed out

-------------------------
curl -Ik https://microtract.xyz

HTTP/2 302
server: nginx
date: Sat, 29 Jan 2022 03:01:11 GMT
content-type: text/html; charset=UTF-8
location: https://microtract.xyz/login
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
(rest omitted)
3 Likes
5

the result of the curl is as follows

'
root@cloudier:~ # curl -I http://microtract.xyz
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sat, 29 Jan 2022 03:45:28 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive

1 Like
6

I see. But, that's not what happens from the public internet. Rudy showed this link earlier but try this - it won't work (will timeout).

Does your device assign its own IP for that domain name? (hosts file, /etc/resolv.conf, ...)
I am not familiar with your config but something is directing traffic differently for you.

Can you try using a cell phone and NO wifi (so, a cell signal) with the Let's Debug link? Or some other device not on your network?

UPDATE: Make sure to click Rerun test on its test results page or start a fresh test with Let's Debug

3 Likes
7

this is all that is in the resolv.conf of the jail


search microtract.xyz
nameserver 1.1.1.1
nameserver 8.8.8.8
1 Like
8

I am not that concerned with why your curl tests fail. I was just pointing out ideas for you to look at.

What matters for Let's Encrypt is access from the public internet. The Let's Encrypt server must be able to reach it with http to satisfy the http challenge.

What happens when you try the Let's Debug test site? From anywhere as that is on the public internet. Or, try http accesses to your site using your phone with a cell connection.

3 Likes
9

it fails with the jail, but if I make my truenas have the ip of the forwarded port I am able to access

10

I don't understand what that means.

When you can connect with letsdebug.net that is the first step to getting a Let's Encrypt cert (the main purpose of this forum)

I don't see a connection from Lets Debug or my own system

I don't know what else to say. Good luck

2 Likes
11

I'm biased, but I think my script is a better way to set up Nextcloud on Free/TrueNAS, and it completely automates the certificate process--but that's neither here nor there at this point; the problem is (as others have said, but just to make it explicit) that your server just isn't responding on port 80. This points to either a problem with your port forwarding setup, or an ISP that's blocking port 80.

4 Likes
12

I don't know what happened, but when I test it over TLS-ALPN-01 using let's debug it works now. Now is there a ready made script to go by that?

13

That's an overstatement of the "test" conducted.
It passed the test
and
it worked
(in this case) are two very different things.

[try that same test on any other site that you know doesn't support TLS-APLN]

1 Like
14

My script uses Caddy as the web server, and Caddy uses TLS-ALPN-01 by default to obtain a cert. AFAIK, certbot is unable to use the TLS-ALPN challenge.

2 Likes
15

I just meant the port seems to be open to the public now

https://www.yougetsignal.com/tools/open-ports/
Port [443](https://en.wikipedia.org/wiki/Port_443) is open on [microtract.xyz](https://microtract.xyz).
1 Like
16

Now I am just hunting for one that works with nginx

17

If you are not too concerned with logs, there is a hack that can get nginx to use TLS-ALPN-01
It involves running nginx on multiple ports and using it to proxy back to itself on different ports (depending on the request type).

2 Likes
18

that sounds totally horrendous... how is it done quickly?

19

If you have a NAT device, then NAT outside:443 to inside:9443 [as an example]
Then nginx can listen on 443, 7443, 9443
9443 listens and decides:

  • if regular HTTPS, then proxy to 443 [to regular sites]
  • if TLS-ALPN, then proxy to 7443 [to ACME client listening as --standalone --port 7443]

If there is no NAT device, then switch the listening ports around:

  • 443 becomes the listener to decide where to proxy the request
  • 9443 can become the port for all the real sites
  • 7443 can still be used by the ACME client

[yeah, that was the short story]

1 Like
20

Why not use the "No NAT device" port scheme also for cases with a NAT device? Shouldn't matter, right?

1 Like