My Certbot is unable to verify my domain via the HTTP-01 challenge

Website, Application, Performance DNS & Network
1

What is the name of the domain?

yotehouse.cc

What is the error number?

Internal Error

What is the error message?

Internal Error

What is the issue you’re encountering

Cannot verify domain over http

What steps have you taken to resolve the issue?

Updated Nginx Proxy Manager, reinstalled linux server, reinstalled NPM server, reached out to Let’s Encrypt community, reached out to Reddit community, reached out to NPM github, opened ports 80/443, disabled all firewalls.

What feature, service or problem is this related to?

DNS not responding/updating

What are the steps to reproduce the issue?

Request an SSL through Let’s Encrypt from NPM
Internal Error

2

Is the certificate you’re trying to create meant to be for yotehouse.cc, www.yotehouse.cc, or something else like example.yotehouse.cc?

Currently, there are no AAAA or A records, neither on yotehouse.cc nor www.yotehouse.cc, and as such, nothing will be able to verify these two names via HTTP.

4

It’s not that weird after all. IPv6 has been the future of the Internet since 1996.

That said, -

Many residential ISP’s have been moving more and more towards providing you with an IPv4 address, that they run Carrier-grade NAT (CGNAT) on, to conserve IPv4 addresses, as there simply aren’t enough of them, for all the devices that the population wants to put on the Internet.

Carrier-grade NAT (CGNAT) can to some degree be seen as another layer of NAT, similar to the layer of NAT from your own router.

If you’re under Carrier-grade NAT (CGNAT), then port 80/443 for the public IPv4 address you operate from, would also need to be open in that Carrier-grade NAT (CGNAT) layer, in a similar way as it would need to be in your own router.

Are you looking to have these hostnames Proxied (:orange:) by Cloudflare?

If yes, you do have some alternatives:

  1. Use Cloudflare as a IPv4+IPv6 frontend, for your IPv6-only origin.

If you have IPv6 connectivity, where opening port 80/443 in your “own” firewall/ (e.g. router) works just fine over IPv6 from external sources, - you do have an alternative.

Create an AAAA record ( → INSTEAD of the A record! ← ) in your Cloudflare, that is Proxied (:orange:), pointing to the IPv6 address.

Now, when I’m visiting example.yotehouse.cc, I’m going to reach Cloudflare, where Cloudflare will provide the IPv4 AND IPv6 for their HTTP Proxies to the public.

Once Cloudflare receives the traffic, Cloudflare will then pass it on to your IPv6 address (AAAA record), that is behind the Cloudflare’s HTTP Proxies.

  1. Use a Cloudflare Tunnel.
2 Likes
6

It was solely meant as an illustration to get a better understanding on how it works, - and not as indicating that your ISP would have such options.

If your ISP allows you to purchase a static IPv4 address, that would likely be the only option for you, if you insist on the IPv4 way.

And in this case, it won’t be Cloudflare that interfere with the traffic in any way.

That leaves you pretty much with only one option left.

Get a static IPv4 address from your ISP, where you can open ports.

Those 192.168 addresses are private addresses, and won’t work on the public Internet, so if that “someone” is from outside your own network (such as e.g. if that someone would be me), that will never work.

It isn’t completely impossible to look in to a solution to the problem.

It gets complicated though, and especially when you have severe restrictions, such as e.g. Cloudflare decrypting your traffic, and similar, then the options (if any are left) are becoming really sparse.

1 Like
7

Get a static IPv4 address from your ISP, where you can open ports.

I have a static IPv4 address internally reserved with ports 80 and 443 open. These have been tested to accept and send traffic

Those 192.168 addresses are private addresses, and won’t work on the public Internet, so if that “someone” is from outside your own network (such as e.g. if that someone would be me), that will never work.

That’s the point behind NPM. Cloudflare sends “family” to my public IP and ends at my Raspberry Pi. The Pi then sees “family.yotehouse.cc” and says “oh, I need to send this to 192.168.x.x:xxxx internally”. This is what I have done for the past month with no issues until last week.

I have been messing around with Cloudflare as this is the only place I can see the issue being, and I can successfully get an SSL certificate from NPM only by using a DNS challenge token. However, I can never access, for example “family.yotehouse.cc”; it just times out. I currently have “yotehouse.cc” and “*.yotehouse.cc” under an “A” record and “family.yotehouse.cc” under a CNAME record. Before, I had everything under an “A” record.

8

“Internally” is the key here.

Let’s Encrypt, and other certificate authorities, will require you to have a public IPv4 address, in other words externally, that you’re able to open ports through, in order to be able to perform able to perform the HTTP validations successfully.

Because your external IPv4 address (supplied to you by your ISP) were previously a “public” one, that allowed you to open up ports, until last week.

Your explanation above pretty much explains that, e.g.:

The most common thing here, is that they moved your IPv4 connectivity behind Carrier-grade NAT (CGNAT).

That change of the IPv4 connectivity means you’re SOL, and cannot open any ports any more, on the IPv4 protocol.

You will need your ISP’s assistance to fix that, if you want it to work somewhat like it did before.

This one is also consistent with your explanation above, e.g. that your ISP messed up the stuff, by moving your IPv4 connectivity behind Carrier-grade NAT (CGNAT), so that you’re no longer able to open ports to the public Internet any more.

The IPv4 address that you can see on one of the many different “what's my IP address?”-checkers out there, you will need to be able to access port 80/443 through that one.

If you for whatever reason (e.g. Carrier-grade NAT (CGNAT)) are unable to do that, then you cannot use the HTTP validations.

Communication about how to fix that, so that you can open up ports again, will therefore need to go through your ISP.

9

This is exactly what I was looking for. Thank you for explaining this in a way that I can understand.

I’m supposed to have a work-order put in for tomorrow to get this all situated. I’m assuming I need to tell them I would like a static IPv4 address then?

10

You’re welcome. :slight_smile:

The majority of all ISP’s should understand the request for a “static” or “public” IPv4 address, with either of those two words.

Start by using the term “public”, rather than “static”, and if that doesn’t go well, you can then move towards “static”.

Most ISPs will charge extra for a static IPv4 address, which can be mixed between set up fee and/or monthly fee, or even a combination of both.

As a start, you can just explain to them as it is, - or even refer to the previous call and the explanation, and tell them that you are unable to reach your machines from the outside, and that you understood by a previous call that they moved you to IPv6, but that you need a public IPv4 address, so that you can access your computers remotely, and that you therefore request that they switch your connection back to how it was before, with a public IPv4 address.

This way, you can also see what they have to say (or even offer) in regards to that, and whether they will try to charge you any additional fees for it, or not.

The options available may vary a lot, e.g. from ISP to ISP, and country to country.

11

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