Challenges are failing but I see the HTTP traffic

Help
1

We have a Mitel Ingate siperator that uses ACME/Let's Encrypt to add to it's outward facing interface and it has been failing renewal for the last few months (maybe started in April or May.)

The appliance log only has the following error - acmemonitor: Challenge did not pass for:

However, I've run a packet capture on the WAN side of our firewall and I see 3 challenges and the responses for each. I saw a topic on here that there should be 5 challenges now? Is there supposed to be 5 and is it common for an ISP to block traffic? We don't believe they are and without know what IPs challenges could be coming from, we can't open a ticket a ticket.

2

Welcome to the Let's Encrypt Community.

They could come from anywhere. Let's Encrypt does not publish their origin IPs. If you are using HTTP-01 (or ALPN-01) challenges, it is crticial that you do not block IPs.

While it does not fully replicate the Let's Encrypt challenge, you may want to test with Let's Debug to see if it provides any additional insight.

3 Likes
3

Yes, I'm aware and understand why Let's encrypt does not publish IPs. However, I seem to have hit a wall with using Let's encrypt as it appears everything is working fine from our side.

Thanks for sharing the debug tool - I'm currently in the queue.

2 Likes
4

You should see one request from our datacenters, and then 4 requests from AWS us-east-2, us-west-2, eu-north-1, and ap-southeast-1. You can use AWS’ IP lists if you want to understand the regions better.

Seeing three requests suggests country-level blocking perhaps, as there are 3 in the US.

5 Likes
5

I'm still trying the debug tool, the first time it was cancelled or stopped by the servers (don't recall the exact language) and I'm trying a second test and the queue time is now over 27 minutes.

We have another server that uses Let's encrypt and it just renewed last month - uses the same ISP but a different IP in the block we have.

I must be missing something. Hopefully I can get the debug to work later and provides more info.

6

That is very unusual but I get the same result. I alerted the Let's Debug developer

There usually is no que although comms to your domain / DNS can sometimes cause long reply times. This looks like a Let's Debug app problem.

We have other tools if you share your domain name we can look. That said, given your pattern it very much looks like a geographic based firewall.

6 Likes
7

Let's Debug had an extended outage, sorry. Should all be fixed now.

6 Likes
8

I'm an idiot.

After way too much time, I realized we were geoblocking. I missed it in the packet capture because i was only looking at HTTP traffic not TCP on port 80. I ended up finding the two additional IPs that were trying to validate and tracked down the policy in our firewall that was blocking them. After that it worked as expected.

Appreciate the help!

8 Likes
9

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