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 | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is: test4.virtualized.app or test3.virtualized.app or test2.virtualized.app or test1.virtualized.app
I ran this command:
certbot certonly --installer nginx -d test4.virtualized.app
It produced this output:
23.177.8.15: Fetching Pterodactyl Timeout during connect (likely firewall problem)
My web server is (include version):
nginx version: nginx/1.22.1
The operating system my web server runs on is (include version):
Debian 12
My hosting provider, if applicable, is:
OVH
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):
certbot 2.1.0
Hello,
my subnet 23.177.8.0/24 is just getting blocked in my opinion, if you do checks from outside multipile regions all works fine, ONLY letsencrypt says that it gets a timeout.
The subnet is announced since a week. the GEO data is not right yet, but im in process of getting that placed. now is my question, why is it getting blocked? how to resolve this?
Your opinion is incorrect--Let's Encrypt simply does not block subnets in this way. On rare occasions, they'll block inbound connections from certain IPs or networks, but you're clearly well past that if they're trying to retrieve a validation token from you.
If you're using any sort of geo-blocking, disable it and try again.
alright. so what else could it be? what regions of blocking we are talking about? i dont have any geo blocking rule with my provider and i dont plan it to.