I get the following error message below. However, my port 80 works fine and I can successfully get a text file from ACME challenge directory (e.g., http://my.domain/.well-known/acme-challenge/test.txt fetches the file as expected). I'm running the apache server.
For your information,
The firewall is off.
I tried with the "Limit Tracking IP" off, but no help.
I did not have this problem earlier than macOS 26.
Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.
From what I can tell from my testing, your server is unreachable via the A record in your DNS. Since you've chosen to anonymize your domain name and IP address, this is about all I can provide:
Thanks for your testing and comment. This seems beyond my tech level of understanding. It is quite frustrating that the letsencript verifier cannot reach my sever when I can externally access the challenge file through port 80. I will contact my DNS managing team, but specifically, what should I ask them to test or check?
I contacted my Network Managing team, and they say that the error is due to the "First SYN Drop” policy. Somehow, the letscrypt verifier is rejected by the policy at the first attempt, and then it does not try again. Usually, they say, web clients attempt again for connection. To test this theory, they temporarily excluded my server from this policy, and I could successfully renew my severs’ certificates.
Now, my new question is, is it possible to configure the letsencrypt verifier to adapt to the First SYN Drop policy, which seems to be widely used? Or, if the verifier uses a fixed IP address, they can make an exception rule for the connection from the verifier to my server.
The Let's Encrypt validation servers do not retry failed requests. I doubt very much they would change that strategy. Keep in mind Let's Encrypt issues over 7 million certs per day. There are 5 validation centers around the globe each of which is a collection of servers. Their IP addresses rotate frequently.
There is no practical way to grant exceptions for individual cases.
That all said, I am a volunteer and not a member of staff so this is my personal opinion. I am a very active volunteer but still ...
This issue does not come up frequently.
It sounds like your network team has a way to grant an exception on your end. If that is not viable you should look at using a DNS Challenge. See: Challenge Types - Let's Encrypt
I kinda not sure if CAs are allowed to ignore SYN drop and silently retry: MPIC requires CA drop previous collaboration state when it retries. so when it see first SYN droped it need to vote as fail and if one retires it needs to be new vote for quorum.
