We are also experiencing problems with certificate renewals when using the redirect method.
We captured the traffic with tcpdump on both servers: the web server that sends the redirect, and the central server that handles the renewal. We can see that Let's Encrypt connects successfully to the web server and receives the redirect URL. We have tested this with both HTTP and HTTPS redirects.
We can then see Let's Encrypt sending SYN packets to the central renewal server five times, and our server replies to each of them. However, the TCP connection is never fully established, and the renewal eventually fails with the error message "loop detected."
The issue appears to be completely random. If we simply run the renewal again, it usually succeeds without any changes on our side. However, we have noticed that these failures seem to have become significantly more frequent over the last 30 days.
@lazat77 I moved your post to its own thread. Based on your description it does not sound like it is caused by the same thing as the thread you posted on. We like each unique problem to be its own thread to make it easier to focus on your specific problem.
Your description sounds very familiar. The first post in a new Help thread is shown the below questionnaire. Please answer as much as you can of the questions you did not already provide info for. Thanks
================================================
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Yep, we'll need your domain to check how the http redirects look but you mention a "central renewal server", so please say more about how you achieve such a thing. If you are using http domain validation then all the http requests to /.well-known/acme-challenge/<challenge key> have to provide the same response from multiple geographic locations.
f any Let's Encrypt administrator or engineer would be interested in investigating what is happening from your side, I would be happy to provide the IP address of the affected server, along with timestamps of failed attempts. This may make it possible to compare what we see in our packet captures with what is happening on the Let's Encrypt side.
I have full access to webbserver, renewal server, egde routers, We use apache for the webbservers. we dont use controlpanels for this, (bash) and the URL for the renewals is like http://renalserver.example.com/.well-known/acme-challenge/<challenge
This community serves as first level support. We would be happy to take a look at this if you provide an actual domain name.
It actually sounds very much like what we have seen at several GoDaddy hosted sites around the world related to the kind of firewall they use. Of course, it can be something else.
This community has helped a vast number of people with all sorts of problems. This is what allows the very small Let's Encrypt team to focus on higher priorities and provide these services for free.
If you don't wish to provide more info here we won't be able to do much. And, I don't think LE staff will get involved until you've at least gone through this level of support. But, maybe your case will be different.
