"Connection reset by peer" when trying to curl LE API

Help
#1

Hi,

I'm trying to get a LE certificate on my Synology NAS. But I always get the same error message : "Can't connect to Let's Encrypt, verify that your domain name is valid".

My domain is valid. I read in another post that I could try to join the API with curl :

curl -I acme-v02.api.letsencrypt.org

And I get this message

curl: (56) Recv failure: Connection reset by peer

Can you help me ? Is there a specific port to redirect/open ?

Thanks in advance.

#2

Hi @Harkonnen

that's what you have to fix.

Your unknown system must be able to connect Letsencrypt.

Buggy network, domain configuration, dns - a lot of problems may be the reason.

#3

In order to start troubleshooting, we’ll probably need to know your IP address and the result of a traceroute to the API’s hostname.

#4

Here is the output of a traceroute :

traceroute to acme-v02.api.letsencrypt.org (172.65.32.248), 30 hops max, 38 byte packets
1 192.168.1.1 (192.168.1.1) 1.357 ms 0.650 ms 0.514 ms
2 80.10.233.81 (80.10.233.81) 15.835 ms 16.774 ms 17.824 ms
3 ae111-0.ncbor202.rbci.orange.net (193.249.214.238) 23.538 ms 31.764 ms 23.053 ms
4 ae42-0.nipoi202.rbci.orange.net (193.252.100.30) 24.913 ms 24.843 ms 24.618 ms
5 ae40-0.nipoi201.rbci.orange.net (193.252.160.45) 26.413 ms 26.086 ms 25.406 ms
6 193.252.137.18 (193.252.137.18) 29.714 ms 30.060 ms 31.246 ms
7 hundredgige0-8-0-31.auvtr5.aubervilliers.opentransit.net (193.251.133.76) 29.328 ms * hundredgige0-9-0-33.auvtr5.aubervilliers.opentransit.net (193.251.151.54) 30.120 ms
8 81.52.200.209 (81.52.200.209) 29.799 ms 81.52.200.147 (81.52.200.147) 31.138 ms 193.251.129.24 (193.251.129.24) 30.499 ms
9 hundredgige0-2-0-14.partr2.saint-denis.opentransit.net (193.251.128.170) 30.258 ms hundredgige0-3-0-14.partr2.saint-denis.opentransit.net (193.251.128.254) 30.167 ms 193.251.129.32 (193.251.129.32) 31.842 ms
10 cloudflare-17.gw.opentransit.net (193.251.150.160) 31.085 ms 30.678 ms *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

#5

Hi, the issue is that you are trying to connect to the API using http:
curl -I http://acme-v02.api.letsencrypt.org : connection reset by peer
curl -I https://acme-v02.api.letsencrypt.org : will be OK

#6

Hi @webprofusion

I don't think that's enough.

Traceroute is protocol-unspecific. And traceroute should work.

See

D:\temp>tracert acme-v02.api.letsencrypt.org.

Routenverfolgung zu ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com [2606:4700:60:0:f53d:5624:85c7:3a2c]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms fritz.box [2003:e9:ef31:7200:f2b0:14ff:fe0e:fe2c]
2 5 ms 4 ms 4 ms 2003:0:8003:9800::1
3 * * 7 ms 2003:0:1005:c00c::2
4 7 ms 6 ms 7 ms cloudflare-ic323372-bei-b2.ip.twelve99-cust.net [2001:2000:3080:d55::2]
5 6 ms 6 ms 6 ms 2606:4700:60:0:f53d:5624:85c7:3a2c

Ablaufverfolgung beendet.

D:\temp>tracert -4 acme-v02.api.letsencrypt.org.

Routenverfolgung zu ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com [172.65.32.248]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms fritz.box [192.168.0.1]
2 4 ms 4 ms 4 ms p3e9bf075.dip0.t-ipconnect.de [62.155.240.117]
3 * 8 ms 7 ms b-eh3-i.B.DE.NET.DTAG.DE [62.154.47.18]
4 10 ms 8 ms 7 ms b-eh3-i.B.DE.NET.DTAG.DE [62.154.47.18]
5 29 ms 24 ms 23 ms 4.68.62.205
6 23 ms 22 ms 23 ms ae-2-3602.edge3.Berlin1.Level3.net [4.69.159.5]
7 32 ms 28 ms 27 ms unknown.Level3.net [212.162.40.34]
8 27 ms 26 ms 26 ms 172.65.32.248

Ablaufverfolgung beendet.

First is ipv6, second ipv4.

@Harkonnen : Your domain name is required. May be you have a blocking Cloudflare firewall or something else.

#7

Hi @JuergenAuer

I did the traceroute from my own machine, with a dynamic IP. How cloudflare could have firewalled that IP ?
I've just rebooted my modem, so I have a new IP. And the result of the traceroute is the same.

#8

I haven't yet seen the results for you trying

curl -v https://acme-v02.api.letsencrypt.org/directory

To see if this is giving you the same error when trying https as you got when trying http.

1 Like
#9

@petercooperjr

Here it is (just replace -v with -I to get only the header) :

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 06 Apr 2021 13:27:40 GMT
Content-Type: text/html
Content-Length: 2174
Last-Modified: Mon, 05 Oct 2020 22:28:11 GMT
Connection: keep-alive
ETag: "5f7b9dfb-87e"
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

So it works with https... I'm glad to see that. So I suppose my Synology tries to connect LE with http instead of https ?

#10

Interesting. Can you actually try the command I posted, of getting the /directory ? I don't think it would matter, but that's the endpoint that I'd expect your system to be actually hitting.

And just to be clear, you're running these curl commands from the same system that can't seem to connect using its built-in client?

#11

Yes, I'm connected to my Synology via SSH and I execute all these commands on it.

Here is the output of getting /directory :

  • TLSv1.2 (OUT), TLS header, Certificate Status (22):
  • TLSv1.2 (OUT), TLS handshake, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Server hello (2):
  • TLSv1.2 (IN), TLS handshake, Certificate (11):
  • TLSv1.2 (IN), TLS handshake, Server key exchange (12):
  • TLSv1.2 (IN), TLS handshake, Server finished (14):
  • TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
  • TLSv1.2 (OUT), TLS change cipher, Client hello (1):
  • TLSv1.2 (OUT), TLS handshake, Finished (20):
  • TLSv1.2 (IN), TLS change cipher, Client hello (1):
  • TLSv1.2 (IN), TLS handshake, Finished (20):

GET /directory HTTP/2
Host: acme-v02.api.letsencrypt.org
User-Agent: curl/7.54.0
Accept: /

< HTTP/2 200
< server: nginx
< date: Tue, 06 Apr 2021 14:38:09 GMT
< content-type: application/json
< content-length: 658
< cache-control: public, max-age=0, no-cache
< x-frame-options: DENY
< strict-transport-security: max-age=604800
<
{
"Ni_5CVkF_90": "Adding random entries to the directory",
"keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
"meta": {
"caaIdentities": [
"letsencrypt.org"
],
"termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
"website": "https://letsencrypt.org"
},
"newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
"newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
"newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
"revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
}

2 Likes
#12

A random thought: Can you try to see if there are new software updates available for your Synology machine?

#13

No software updates at this time

#14

The curl test is a red herring (i.e. it's not the same problem), your domain is not resolving back to your synology box or it is genuinely not a valid public name. If you can't share your domain here type it into https://letsdebug.net instead. In particular make sure that if you have both an IPv4 address and IPv6 address for your domain/subdomain make sure they both point to the same thing and that if you do point an IPv6 address to it that your modem will actually work with that (some equipment does not).

1 Like
#15

And you also need to be presenting your synology nas on port 80 for your public IP address (even if you then nat to a different port internally), if you want to do http validation. If you can't do that you need to use DNS validation instead as Let's Encrypts http validation happens (starts) on http port 80.

1 Like
#16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.