We build websites for clients and utilize Let’s Encrypt. However, every now and then when the client cuts over their DNS from old host to us, the let’s encrypt will fail. It is very hard to troubleshoot whether the response is hitting our server or the old server. It would be nice to see what DNS resolve was being hit. Even if DNS propagation sites say it is fully propagated, Let’s Encrypt still fails every now and then hitting the old site.
Feature Request: Have a --debug flag that would allow to see detailed dns information about what record is being used to handle the request.
Also, could you give an example of this? Let's Encrypt doesn't rely on the concept of DNS propagation because, unlike desktop computers' DNS resolvers, it doesn't use any DNS caches but always directly queries the authoritative DNS servers. So this should never happen at all.
I removed a few things from the command but that is the general base command we use.
Every now and then we get the unauthorized response and the detail being “300 Multiple Choices” or a simple “404”.
This is my typical work flow in both situations.
I check the logs on the server to see if a request came in for the path of domain.com/.well-known/ and there is nothing. I then check to make sure the webserver is configured correctly. It is. My first guess now is that it is hitting the wrong server. I do a dig and see that the IP address is correct. I access the website and see that I am hitting the correct server. The response given appears to be Apache (due to the Doctype and such), so it definitely isn’t us unless some developer is doing some new custom stuff. I will retry a few more times to see if it was just a hiccup. It would just be nice to see what IP address is being used. It would eliminate a lot of this headache. We would know right away. It is hard to troubleshoot without seeing anything in access logs. I will
Now that I think about it, I guess this might be a certbot feature request then.
If you create a new order, Letsencrypt creates a new order-url (sending back in the Location-Header).
This order-page (you can open it in a normal browser) contains the challenge urls (one domain name - one challenge) and the finalize-url (later also the certificate url).
So if a check is invalid, there you can find the details.
I never knew about that API challenge URL in the debug logs. That is exactly the information I have always been searching for! Probably mostly on laziness on my part skimming through this specific log and never visibly seeing any information that helped without going to the links.
So, certbot -v already shows all of this information, but maybe it shows more information than is useful and it would be helpful to have something in between?
