[URGENT] Unable to obtain a certificate via certbot

Help
1

Hi, I'm trying to install a certificate on my Pterodactyl wing, and I get this certbot error.

It's now been 24h00 since the DNS propagated, and I see that on DNSChecker for example that it's completely propagated. Even when pinging I can see the VPS ip.

I don't really understand the error, especially as I have another wing that worked perfectly. So I don't think my domain provider is to blame.
I'm putting this ticket on urgent because I need this vps up and running quickly.

I hope with all my heart that you can help me, and I thank you!

My domain is: de2.azurware.fr (and the panel is "host.azurware.fr"

I ran this command: certbot certonly

It produced this output:

1: Spin up a temporary webserver (standalone)
2: Place files in webroot directory (webroot)

Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel): de2.azurware.fr
Requesting a certificate for de2.azurware.fr

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: de2.azurware.fr
Type: connection
Detail: 92.118.207.103: Fetching http://de2.azurware.fr/.well-known/acme-challenge/otzeEILOXuihmd4w5FeGi3pZ9CYVBFJW9BHBlGXL5u8: Connection reset by peer

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.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version): I don't know, I'm using Pterodactyl

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

My hosting provider, if applicable, is: pristis.fr (and my registrar is PlanetHoster)

I can login to a root shell on my machine (yes or no, or I don't know): 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): yes, pterodactyl, but there is just a wing

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.21.0

1 Like
2

First, most of the help you receive here is by unpaid volunteers. Asking for help urgently won't change the response you get.

There is no problem with your DNS. In fact, Let's Encrypt servers use your authoritive servers so don't have to wait for worldwide propagation. I can also poke one of your (many) other open ports with tcp so the general comms path looks ok.

Now, debugging the --standalone authentication is harder than most.

Enter this command

certbot certonly --standalone --dry-run --debug-challenges -v -d de2.azurware.fr

This will show you a URL and pause. Leave it paused and use a machine outside your network to try to reach that URL. Use your cell phone with wifi off, for example, to use your carrier's network.

You need to find the reason you won't be able to reach that URL. The Let's Encrypt servers were actively being blocked by something on your system (reset by peer, you are the peer in this context)

While Certbot is paused you could post the URL it displays and maybe a volunteer will try it and see something you might not.

Update: added missing certonly

6 Likes
3

Thank you for your reply. But I have a problem, there is it :

root@de2:~# certbot --standalone --dry-run --debug-challenges -v -d de2.azurware.fr
--dry-run currently only works with the 'certonly' or 'renew' subcommands ('run')
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /tmp/tmpofr6zm97/log or re-run Certbot with -v for more details.
root@de2:~# certbot --standalone -run --debug-challenges -v -d de2.azurware.fr
usage:
certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...

Certbot can obtain and install HTTPS/TLS/SSL certificates. By default,
it will attempt to use a webserver both for obtaining and installing the
certificate.
certbot: error: unrecognized arguments: -run
root@de2:~# certbot --standalone certonly --debug-challenges -v -d de2.azurware.fr
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Requesting a certificate for de2.azurware.fr
Performing the following challenges:
http-01 challenge for de2.azurware.fr

Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.

Press Enter to Continue
Waiting for verification...
Challenge failed for domain de2.azurware.fr
http-01 challenge for de2.azurware.fr

Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: de2.azurware.fr
Type: connection
Detail: 92.118.207.103: Fetching http://de2.azurware.fr/.well-known/acme-challenge/s_TjiehxWMNplsvnOrFu9PuYuVYFjylNH1RTfw5LgSo: Connection reset by peer

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.

Cleaning up challenges
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

Thanks !

2 Likes
4

Oh, sorry, I forgot the certonly in the command. It should be this (and do keep the --dry-run)

certbot certonly --standalone --dry-run --debug-challenges -v -d de2.azurware.fr

You should see something like below. When it says "Press Enter to Continue" do not do that. Leave it paused and test it as I described. Or, post the URL here

Performing the following challenges:
http-01 challenge for de2.azurware.fr

Challenges loaded. Press continue to submit to CA.

The following URLs should be accessible from the internet and return the value
mentioned:

URL:
http://de2.azurware.fr/.well-known/acme-challenge/YX-2D1i-dspL69smknvumu-SlM0ip0SD5HthzkvbjaI
Expected value:
YX-2D1i-dspL69smknvumu-SlM0ip0SD5HthzkvbjaI.mgHwhToeOgo6Nr4Ly01jMHNVpII2Pw3tUlsjR3uYyAc

Press Enter to Continue

5 Likes
5

Thank you !

It seems to be loaded. There is the URL (I thnik that it's her) : http://de2.azurware.fr/
I'm not going to lie to you that I don't understand it at all so I don't know how to do it. All I can say is that the URL is accessible with a message "ACME client standalone challenge solver". I tested it on my computer and on my phone, activating only 4G.

Thanks !

1 Like
6

So, does your cert request work then?

If not, I suspect something is blocking only some requests. That's why I asked you to post the URL while paused so I could fully evaluate access to your server. It would go quicker if you just followed instructions.

3 Likes
7

I don't think I understand everything, I just gave you the URL I was given...

This is what I am told in the console:

root@de2:~# certbot certonly --standalone --dry-run --debug-challenges -v -d de2.azurware.fr
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Account registered.
Simulating a certificate request for de2.azurware.fr
Performing the following challenges:
http-01 challenge for de2.azurware.fr

Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.

Press Enter to Continue

So I guess the URL is de2.azurware.fr?
I'm trying to follow what you're telling me, but I have the impression that we're not seeing the same thing.

8

Huh. We are not. See my post #4 for what I see. I am using the latest Certbot version 2.6 but your 1.21 is not all that old. Yours doesn't seem to recognize the -v though since it suggests you include it.

Well, leave it paused and just let us know when it is paused. I can try something else even without the full URL

(upgrading is described at https://certbot.eff.org)

Update: I just checked and see the -v flag was only supported starting 1.24.0. So, I can work without it just let me know when paused

3 Likes
9

I'm really sorry for the confusion. I never touch this stuff so the slightest hiccup or technical word confuses me! Thanks for your time!

This is currently on pause.

1 Like
10

OK. You have a firewall setting that is blocking certain requests. Requests that look like they are from a "normal" browser work. But, other requests are blocked which include the kind that the Let's Encrypt server uses.

I say this because I can see your domain just fine from many points around the globe so a geographic based firewall is not involved.

And, then I saw this

(a plain curl request.  that is, not a browser)
curl -I http://de2.azurware.fr
curl: (56) Recv failure: Connection reset by peer

(mimic a browser, this 501 error is actually a successful test)
curl -I http://de2.azurware.fr -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 Edg/114.0.1823.55"
HTTP/1.0 501 Unsupported method ('HEAD')
Server: BaseHTTP/0.6 Python/3.10.6

NOTE: Did you just fix this because as I am posting the symptom looks different?

4 Likes
11

Thank you for this crucial information!

No, I haven't done anything, he is still in pause

Edit: It's true that it's very strange from what I understand...

1 Like
12

OK. It isn't related to the user-agent of the request. But, you do have some odd firewall setting.

I started a fresh test server which had a new IP address. When I tried reaching you the first request failed but then they worked. I'm not sure what to suggest other than review all your network config for any kind of firewalls and turn them off.

The Let's Encrypt servers will often be different IP addresses as they change frequently.

Use the --dry-run while testing because too many failed requests to production will get you blocked for an hour. So, test with this

certbot certonly --standalone --dry-run -d de2.azurware.fr

Here's what I just saw from a fresh test server and new IP

(first request)
curl -I http://de2.azurware.fr
curl: (56) Recv failure: Connection reset by peer

(all after)
curl -I http://de2.azurware.fr
HTTP/1.0 501 Unsupported method ('HEAD')
Server: BaseHTTP/0.6 Python/3.10.6
Date: Sun, 25 Jun 2023 15:45:43 GMT

curl -I http://de2.azurware.fr
HTTP/1.0 501 Unsupported method ('HEAD')
Server: BaseHTTP/0.6 Python/3.10.6
6 Likes
13

This is what I am seeing, in addition to your findings:

PORT    STATE  SERVICE
80/tcp  open   http
443/tcp closed https
4 Likes
14

That's what I'd expect to see when --standalone is paused.

Both those ports were closed when --standalone is not running (many other ports are open though - like all of them!)

5 Likes
15

That's interesting, thank you once again!

From what I can see there's no firewall active on the server, so I'll contact them and have a closer look.

2 Likes
16

Firewalls come in many forms and can be enabled at many places.

@MikeMcQ Doesn't this look like those pesky Alto Paulo firewalls to you perhaps?

5 Likes
17

Not any of the usual symptoms. I was getting "reset" using just the domain (no URI) in the HTTP request.

It reminds me of another thread though but I can't recall enough details for a productive search.

They now have nginx listening on port 80 so that's easier. But, I still see a "reset" on a fresh request. The new info is that it isn't just the first http request from a new IP. It's the first http request always (or very often anyway). After the reset you can make a number of successful requests. But, if you don't make any requests for some minutes you will get a reset again followed by successful. This repeats.

The number of "some minutes" in this case is around 5. Not sure what that other thread was but it had the same pattern of: reset, success, success, wait X minutes, reset, success ...

curl -I http://de2.azurware.fr
curl: (56) Recv failure: Connection reset by peer

curl -I http://de2.azurware.fr
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Sun, 25 Jun 2023 16:57:32 GMT

curl -I http://de2.azurware.fr
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Sun, 25 Jun 2023 16:57:34 GMT

curl -I http://de2.azurware.fr
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Sun, 25 Jun 2023 16:58:16 GMT

(5 minutes later)
curl -I http://de2.azurware.fr
curl: (56) Recv failure: Connection reset by peer

curl -I http://de2.azurware.fr
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Sun, 25 Jun 2023 17:04:11 GMT
4 Likes
18

Perhaps some anti-hacking firewall which assumes any port-scanner/hacking tools tries once and ignores the host if it sees a Connection reset by peer that first time?

4 Likes
19

Everything is back to normal, everything works. I'm told it was a CIDR problem on my host's machine.

I sincerely thank you all for your help and your time!

2 Likes
20

I beg to differ but if you are happy I am happy. I just tried this again and ...

curl -I http://de2.azurware.fr
curl: (56) Recv failure: Connection reset by peer

curl -I http://de2.azurware.fr
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Sun, 25 Jun 2023 17:19:35 GMT
4 Likes