Generating Lets Encrypt Certificate - requested host does not resolve to IP

Observing this problem: Generating Lets Encrypt Certificate - requested host does not resolve to IP

However, I’ve tried setting the address in sip settings to the IP listed and also to the hostname

The http link is resolvable - I’ve emailed it to my cell phone and disconnected from wifi and verified it is reachable.

Can I force FreePBX to ignore the IP check before attempting to request a certificate from lets encrypt?

The external IP address of your PBX must resolve to the domain name you are requesting a certificate for if you are using acme HTTP-01 challenges ( which you are :wink: )

From a shell


should agree with what


It’s not an LE or acme restriction, it’s Sangoma/FreePBX nonsense. The outbound request is NAT’ed to a different IP and FreePBX thinks the config is invalid when it’s not.

This is FreePBX causing problems by trying to be smart, but really being dumb.

This happens if the address the outbound request comes from does not match the resolved IP address of the cert dns name.

Common causes are NAT configuration or multi-homed machines where the default route is not using the same IP as the cert dns address.

If possible remove the device from any kind of NAT, configure 1-to-1 NAT for the server, adjust the outbound default route, or at least for any traffic destined for

There is nothing necessarily wrong with your setup, this is 100% a Sangoma/FreePBX self-inflicted problem. There is no requirement for such nonsense by LetsEncrypt or the acme protocol. There are many possible valid configs where the outbound request IP is not going to match dns cert IP.

I opened a ticket here: Give it some visibility, follow it, vote for it, make a “me too” comment.

If your not opposed to applying a patch, I can send you one that disables the Sangoma phone-home idiocy that causes the problem.

(another down vote for all thing HTTP-01 :wink: )

I will say this is an odd design choice. We use let’s encrypt for several other webapps where the outbound ip doesn’t match the inbound ip. I’m pretty sure that’s common…

It will be complicated to change the ip address assignment as we use all of the addresses in our block for services with one dedicated for outbound traffic as some of the services we integrate with still filter inbound traffic by ip :confused:

It’s a naive, ill-conceived, not thought through attempt at too much hand holding.

Disregarding the actual implementation problems, I don’t think there is any argument to justify adding an extra dependency on

1 Like

Perhaps this should just be a warning, rather than an error.

I could see it as a post-failure diagnostic - your cert request failed, let’s see what we think could be a problem - but making assumptions about the all the possibilities of inbound proxies, outbound proxies, default routes, NAT setup, etc is guaranteed to fail.

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