How and/or where?
Hetzner do not block incoming traffic.
If some internet server1 (LE) has connection problem with some other server2 (my server) then diagnosis should start at the server1 like this:
traceroute server2
Hetzner can not run this command on the LE server.
Seem a bit simplistic in today's Internet, you solution looks fine before Internet worm of November 2, 1988 Morris worm - Wikipedia, but with all the firewalls and specific ports being blocked and routed in various ways it take more than a simple traceroute. Also Hetzner seems to be a pay for service, LE is Free.
ping and traceroute as first diagnosis for the connection related issues are still actual in 2022.
In any case network support staff can use various tools.
I do not think this is subject of this thread.
So Hetzner should be able to the work as well.
Friend! It seems you are excessively optimistic if you know how to diagnose on the provider level the client issue like "some server (I do not know its IP) can not connect to my server at you. Please tell me what the problem with this some server".
I repeat: Hetzner do not block incoming traffic. My server is accessible from around the world.
Let's stop this offtopic at this point.
What exactly is the specific point of this topic?
You seem to have solved your problem previously, just repeat the same actions.
Some LE validation server(s) can not connect to the server requesting certificate. This issue does not relate to the requesting server because it has no limitations for the connections.
Perhaps it's not a specific firewall rule per se, but a MSS/MTU issue due to Minor change to validation networking?
Thank you!
Those changes was in July, 2022
But I faced this issue in May, 2022.
Moreover, this issue is related to only some (not all) LE validation servers.
Most of LE servers successfully connect to my server, but some - not.
I do not know how they works but I geuss that "connection error" in the log actually may be some other type of error on the LE validation server internal software.
I'm not sure if the error can be more specific than "Timeout during connect (likely firewall problem)".
This does NOT mean the issue is related to LE either!
There is whole lot of Internet between those 2 end points and anywhere along the way can be an issue.
Why don't you approach the problem a bit more pragmatically? Just figure out the IP address of the failing validation server, do not wait that someone tells you this. Then report the failing IP to Hetzner that they could check the traffic.
@smon you could change from Let's Encryt as the Certicate Authoriy to another, probably ACME based, Certificate Authority for a possible solution for your issue.
Of course, I know it.
Diagnosis must start at the point which initiated connection (LE validation server).
Ping, traceroute, other tools etc.
LE do not intend to do this for one case being reported on the community forum. I have to accept this.
I already did exactly the same several months ago. Hetzner does not block any trafic from any IP to my server.
That it great. Did they see packets arriving towards your server, when you tried to renew a certificate?
Actually I have no alternatives except migrating back to the http if LE cert will be expired
And why is that the case?
No alternatives seems prone to a single point (or service) failure.
With a paid service, I can see them putting in some effort to keep your business.
With a totally free service, and with you being the only one with this particular complaint, I can't see anyone putting in much effort to keep your business.
Then you need to educate yourself on the available options.
[there are several other FREE ACME certificate providers - which would validate from other IPs]
They do not provide such online diagnostics.
I made tcpdump on the server during renew process. There was only successfull connections and trafic from two LE validation servers. These successfull connections also was presented in the web server access log.
No packets from the third LE validation server were in tcpdump. At all.