I split this post into a new thread since it seems unrelated to the original and its easier to help you with your specific problem in a dedicated thread.
Checking the logs from the server side I see that the underlying error is “No route to host” for the resolved IPv4 address (22.214.171.124). From my own laptop I’m able to ping this IP but not connect to it with openssl s_client:
$ openssl s_client -connect 126.96.36.199:443
connect: No route to host
I’ve asked our operations folks to see if they can suggest a course of action but presently it seems like there are routing issues affecting connections between your server and a few network vantage points (most importantly the Let’s Encrypt validation authority).
Do you have any suspicions about what it could be?
Running some tests from the VA, it looks like there are intermittent connectivity problems. Sometimes resulting in no route to host and sometimes getting connection refused. I’d expect the connection refused just means the server is no longer presenting what the VA expects, but the no route to host is the bigger problem.
I believe the “No route to host” error could be a red herring. I don’t know what particular network stack does this but I’ve seen cases where connecting to one port returns “No route to host” and another connects successfully. Indeed, that’s what I see on this machine right now: connecting via port 80 works and via port 443 doesn’t, giving a “no route to host”! This is then not actually an IP routing problem at all.
I ran a packet sniffer while trying to connect to this host and I saw ICMP code 10 (“Host administratively prohibited”), which my OS nonetheless displayed as “No route to host” even though I don’t regard that as a good explanation of the actual ICMP message. (Also, maybe this means that Boulder should somehow try to log this error more specifically, if the sockets interface provides any way to get that detail, although I’m not at all sure that it does.)
I must’ve forgotten to open the 443 port.
So my website works fine now, it’s just routing that seems to be a problem. As mentioned earlier, I’m not really familiar with linux, or devops in general.
But I’ll find something!
I don’t think there was ever really a routing problem. It’s just that an old Unix tradition has mapped many different site-connection errors from ICMP to the same error message, “No route to host”, even though that doesn’t correctly describe all of them. So I think the only problem was not opening port 443.