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.

not sure what you mean by external DNS

not hosting your own DNS server. specifically it sounds like your DNS server is hosted on your domain provider, not your own local network. you have set up certbot to automatically configure your remotely hosted DNS server for the DNS based renewal.

if DNS based recert was working before then it should be working now.

as I said in my edit, you are likely blocking the return https traffic from the US based let’s encrypt acme servers - so your initial diagnostic is correct. your local firewall is likely stopping the acme servers from talking back to your local host.

you are right back where you started, asking for info in how to allow-list the acme IP ranges. but at least we may now know why it is not working and you are seeing an https timeout even though you are using DNS based certificate renewals.

edit: typos

The DNS server/root isn’t in my home network

are you using external DNS hosting? is it in a (now) blocked country? if so, then your local certbot is unable to update the DNS server records (return traffic from your DNS host is being blocked by your iptables/nftables config).

error: HTTPSConnectionPool(host=‘acme-v02.api.letsencrypt.org’, port=443): Read timed out. (read timeout=45)

yeah, that would suggest an https renewal method. had you previously configured web server renewal at all before switching over to DNS? any other suspicious notifications in the logs?

edit: in thinking about this a little more… the renewal has to be initiated by your host, and that is likely done via https (you talk https to the acme server and tell it you want a renewal by DNS). so, if you are blocking the acme servers then the same issue applies - no return traffic.

not only is noscript your general browsing prophylactic, but it will often render js paywalls climbable. I have no other plugin as loved and as useful as noscript - immediate install on any firefox instance.

dammit! where can I send you my “spat coffee on keyboard” cleaning bill, huh?!

depending on specs it will be a little power hungry, but a good virtualization platform.

yes, the power supplies are likely redundant and the server will complain if they are not both powered.

it will use a VGA connection, but you should be ale to find cheap VGA monitors or cheap adapters.

RAID controllerfor those drives? how many processors and cores? how much RAM? what OS are you planning on running on it? iDRAC included? (if so, likely idrac6, but still usable)

this hardware is very well supported by linux - I have used these older servers extensively. your boss was right to be excited for you. its a great exploration platform that you will be able to do lots of things with.

fire up a live linux distro and get detailed specs on the box - that will guide what you can play with right away.

indeed. it will serve you well in many, many… situations.

or, if you are really lucky, you can poke the right locations and release the magic blue smoke from the chips. super fun and all the cool kids are doing it.

seeing it now on fdroid.

quassel and quasseldroid. its client-server, always on irc connectivity but does require a little setup.

you can access irc servers (if acceptable) and the quassel daemon via Tor. might just change the way you think about irc.

edit: word

…that wireless mac is looking suspiciously shopped and non-existent.

AROS (Amiga) Research Operating System

Wikipedia

Official Page

would run in an emulator or bare metal boot from separate media.

ERROR: Attempted to parse HTML with regular expression; system returned Cthulhu.

classic.

heh, forgot about the standalone web server in certbot. thats a good ephemeral option.

if you are able to run a public web server, then certificate issuance via certbot http challenge works pretty well. the web server can serve a really simple static page with little to nothing on it - but of course its another potential vector into your network.

if your public domain DNS makes use of a supported dns provider or you run your own publically accessible dns server, then dns certbot challenges are great and more flexible than http.

others may suggest neat work arounds for the http challenge issue, but if you have access to a supported dns service I would look at that option. certbot has helpers for quite a few public services as well as support for self hosted dns servers. I run my own public dns servers, so thats the option I chose and use certbot hooks, cron and bash scripts to rsync the updated carts to the propr hosts for the various services I run privately and publicly.

if you are using http cert retrieval, certbot needs a place put the temp. token to authenticate your contrrol of the domain your are creating a certificate for. usually that will be the same webserver you want to serve the certificate from.

if you are not running an actual weberver on port 80 that certbot can insert a token for, certbot cannot complete.

this is, of course, in addition to other possible issues such as ISP port blocking - but without a web server listening on TCP/80, you will have to use other authorization methods (like DNS) to generate a cert.

are you actually running a web server on that host? iirc, certbot will place a temporary token to be served by your web server (Apache, etc.) to show that you actually control the domain you are requesting a cert for.

I switched to DNS based retrieval as soon as let’s encrypt offered it, so its been years since I retrieved certs via http.