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.
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.
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.
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.
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.