Ability to Debug what IP address the request is resolved to


#1

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.


#2

Hi @erik.carlson,

What Let’s Encrypt client are you using? This information is already sent by the CA in error messages.


#3

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.


#4

@schoen

Sure, This is the command we are running and the most recent request we have made.

certbot certonly --webroot -w /srv/www/letsencrypt -d intercontinentalmsp.com -d www.intercontinentalmsp.com

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.


#5

Hi @erik.carlson

look this thread:

You should have an url like this:

https://acme-v02.api.letsencrypt.org/acme/challenge/-U1JMAOSWTXcx5U0IVU_zWy7AI6O_noH_r4DO5Jw4ec/5556829746

There is the information you want to know.


#6

@JuergenAuer
So it seems that in most of these cases there is a floating ipv6 record that shouldn’t be there.


#7

Sometimes :wink:

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.


#8

@JuergenAuer

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.

Thank you so much for this!


#9

If you use v2, then the order-url is something like

https://acme-v02.api.letsencrypt.org/acme/order/yourAccountNumber/yourOrderNumber

Look at your Certbot-protocol if there is such an url. That’s the starting point.


#10

letsencrypt.log should also contain the challenge information itself.

Still, you could make a feature request to have Certbot’s UI expose it.


#11

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?


#12

Yes, that would be beneficial. Information overflow causes people to sometimes do silly things and ignore important stuff :wink:.


#13

I created a feature request issue at


#14

You are amazing. Thank you very much! That is exactly what I originally was looking for.


#15

Well, this is just a feature request rather than an implementation. It remains to be seen whether anyone will implement this promptly. :slight_smile:


#16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.