

agreed. you are using DNS-01 challenges. so the workflow is…
your local certbot machine initiates an https connection to the letsencrypt servers to start the DNS-01 challenge. during this HTTPS dialog, your local certbot is informed of the key material to insert into your DNS records. your local certbot then modifies your netcup DNS server (hosted remotely, not on your local network) with the keying material and the letsencrypt servers verify that the keys are actually there, proving that you control the domain. the letsencrypt serves then issue you the certificate (again, via HTTPS) and your local certbot stores it in your local host.
the issue is most likely stems from the initial HTTPS connection that certbot tries to make to the let’s encrypt servers. while your firewall allows this traffic out, it does not allow return traffic back in because of your explicit blocking of US (and perhaps other) based addresses.
even through your are using DNS for your domain autentocation, your local host - the machine running certbot - is unable to initiate the certificate transfer because of the firewall blocking return traffic.
the two external networks (and, therefore IP ranges/subnets/etc) that are important here are the let’s encrypt servers and the netcup DNS servers. certbot will have to talk to both of these in order to function.









no. I will call it what it is and shame anyone who uses weasel words to excuse the butchery of entire groups of people.
fuck anyone to hell if they choose to do otherwise.