Connection reset by peer issue for renewing multiple SSL certificates

Help
#1

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. crt.sh | mail.galeido.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: mail.galeido.com

I ran this command:
curl -iL https://acme-v02.api.letsencrypt.org/directory

It produced this output:
Some of the sessions goes through and some of the sessions end up with

curl (56) OpenSSL SSL_read: Connection reset by peer, errno 104

My hosting provider, if applicable, is:

Own environment including ASN -> AS210723

I can login to a root shell on my machine (yes or no, or I don't know):

Yes

Comment:

Hi,

I would kindly ask LE staff to review our IPv4 subnet 79.110.238.0/24 it might be blocked or filtered by your DDoS mitigation or other protective measures.

Thanks for advance

Ping @JamesLE sorry for the direct ping.

#2

Are the sessions that sometimes pass, and then sometimes fail, sourced from the exact same IP?
What is the failure rate?

3 Likes
#3

Based on testing now, it is 100% failure rate, everything else works from that specific IPv4 range and from mail.galeido.com

#4

Hi, @galeido,

We're not deliberately blocking your IPv4 or v6 space, or ASN; with the service we use, Cloudflare usually doesn't block traffic except during an active attack. Your prefixes look OK in RIPEstat. What results do you get from a traceroute? I would guess you'll probably reach Cloudflare via your peering at BALT-IX.

2 Likes
#5

Hi @JamesLE,

Thanks for coming back to be quickly.

What comes to Cloudflare, like you said usually doesn't block traffic, which is rather odd in this case. For this specific subnet we route traffic through Finnish provider called Suomicom and secondary through Cogent. Upcoming weekend we will change our core routing to utilise IXPs including FICIX and BALT-IX.

traceroute acme-v02.api.letsencrypt.org

trace seems to stop to Suomicom border-gw in Helsinki. I will reach out to them today.

1 Like
#6

try using icmp traceroute instead of udp traceroute:

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

or maybe even tcp (-T)

1 Like
#7

After swapping primary routing to go through Cogent, everything works normally. Have to reach out to Suomicom's customer support to figure out root cause.

Managed to renew certificates now. Thanks for the quick help.

2 Likes