First Time Problem - certbot failed to auth during secondary validation

Help
1

I'm trying to run an initial run, first time setup. I've confirmed my dns is correct using various online tools.
Also, can I not just place in a text file for it to check? Why all the DNS stuff?

My domain is: a no-ip domain, ggg.sytes.net
I read that this may be the issue, since I'm unable to create a TXT record, but then I also read that this is not a factor anymore. Please advise.

I ran this command: sudo certbot --apache

It produced this output:

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
  Domain: ggg.sytes.net
  Type:   connection
  Detail: During secondary validation: 12.172.231.19: Fetching http://ggg.sytes.net/.well-known/acme-challenge/FR3FRxZK42LFvEN-sRrJi_xJ73ee8PuV3pUblOqeH8k: Timeout during connect (likely firewall problem)

My web server is (include version):
Server version: Apache/2.4.52 (Ubuntu)
Server built: 2024-04-10T17:45:18

The operating system my web server runs on is (include version): Ubuntu 20.04

My hosting provider, if applicable, is: me/myself/I

I can login to a root shell on my machine (yes or no, or I don't know): of course

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
Negative, over

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.21.0

2

Did you read the pinned topic?

6 Likes
3

Nope. BUT - I've so thoroughly researched this topic I've been made aware of DNS checks failing in other countries.

Unfortunately, I didn't see any solution in there. They mentioned some other type of DNS check, but no idea what that is or how to do it.

Again, is it not still possible to just put a text file on my server and tell certbot to check that? Seems like a valid way, especially in lieu of the DNS shenanigans going on...

4

those still need to read A/AAAA record from DNS server to even visit your webserver so nope it wouldn't work.

5 Likes
5

Problem is not just DNS. Usually DNS is not geoblocked, but incoming connections are. Currently your webserver is unreachable on at least port 80 (but probably for any port) from at least 2 remote validation locations.

So to reiterate:

Your problem has nothing to do with any "DNS stuff".

7 Likes
6

So are there any known workarounds? Are we just in limbo land until some country like Azbekistan decides to allow DNS lookups again?

How about all the actual businesses, large corporations, et. al. that are relying on this to renew their certs, are they just SOL?

Are there any other free SSL options to look at?

Thanks!

1 Like
7

I think you're misunderstanding: the problem isn't other countries blocking you, it's your system/network/etc. blocking other countries (or otherwise being inaccessible).

Your server needs to be available, on port 80, worldwide in order to get a certificate from Let's Encrypt using the easiest-and-most-common HTTP-01 challenge.

Sure, plenty. They'll also all need to be able to connect to your server, though.

5 Likes
8

DNS lookups aren't the issue; you can clearly see Let's Encrypt resolved your hostname ggg.sytes.net to the IP address 12.172.231.19.

They probably don't have geoblocking in place or have exempted the paths for the challenge from their geoblocking rules.

To be absolutely clear: Let's Encrypt does NOT use geoblocking. Usually if not all of the time the USERS service provider or firewall does the geoblocking!

There are, but plans are underway so that every publicly trusted CA will need to do some kind of multiple vantage point validation, thus probably having issues with geoblocking.

Let me reiterate: it's NOT Let's Encrypt doing any geoblocking!

Overview of free ACME CAs: ACME CA Comparison - Posh-ACME

7 Likes
9

Aight, thanks a lot guys.

One final question and I think we're done here.

Are these random countries - so if I just keep trying every day, maybe I'll get lucky and they'll pick some countries that play nice with my ISP/Provider?

Thanks!

1 Like
10

Basically, yes, because they can (and probably will) change at random. But as far as I know, they currently don't change very often.

You could also try to find and fix the thing that is doing the geoblocking.

3 Likes
11

How would I approach that? I need clues... like which country is it failing from, and who's actually blocking it. My provider is a local provider that uses AT&T, so maybe AT&T? Do I call my provider or ATT, and tell them Azbekistan is being a problem?

12

You could ask them if they're geoblocking incoming connections from certain countries indeed. E.g. certain countries from Asia and/or Scandinavia.

But maybe it's your own server, I dunno :man_shrugging:t2: 9 out of 10 (if not more) it's something on the server itself.

3 Likes
13

how could it be my fresh install of apache geoblocking other countries? It's just a plain ol vanilla install running the default apache page...
If there's something else to check, I'm all ears, but it's just apache on an ubuntu OS, on a raspberrypi...

14

Should your system be available now? Because I cannot reach it from my own test server hosted in AWS on the US East Coast. (see below)

As for the current countries Let's Encrypt uses, these are described in the thread that was linked to in the first response to you.

curl -I http://ggg.sytes.net
curl: (28) Failed to connect to ggg.sytes.net port 80 after 133443 ms: 
Connection timed out
6 Likes
15

what the....
why, we oughta...

it must be no-ip DNS mucking things up, suely we're not being blocked by USA IP's...

1 Like
16

The DNS resolves just fine. Just timeout with HTTP request. Many of the Let's Encrypt server farms are also in AWS. Maybe your router is blocking all of AWS? Or maybe your ISP settings have something which do that?

6 Likes
17

I would not be surprised that it's my ISP. They've been blocking port 80 and 443 for years, it only started 'working' recently.
This 'ggg' site is just a POC for my real website I want to migrate and host myself, tired of paying for hosting I can easly do myself for pennies per year.
-rant-
This whole DNS mess is so unnecessary. If I can prove it is my domain, which can easily be done securely, w/o 'servers from all over the world which may be blocked coming to verify repeatedly'...totally ridiculous. I've spent lots of time getting this built this far, only to be stopped on the nearly final step, securing it. This reeks of our tech overlords trying to make things harder for us little guys.
-endrant-
If this continues to fail and all I've got is port 80, I will put up self-signed cert, or just run it on 80/HTTP and secure the crap out of it every other way I can. It's only a dad gum wordpress blog.

18

Why are you insisting it's a DNS issue whereas multiple persons have already stated your DNS resolves just fine?

Unless 12.172.231.19 is not your IP address. Then there would be a DNS issue.

If you keep insisting this is a DNS issue, I'm afraid I cannot help you further due to the fact you're simply not listening.

Also, you're very welcome to try to use any of the other free CAs mentioned on the page linked somewhere above.

4 Likes
19

We work much better when real are provided.

  • Real FQDN(s).
  • Real IP(s).
  • Real :beer:
4 Likes
20

I'm aware DNS resolves correctly. I'm listening.
What I'm saying, maybe not as clearly as I'd like, is that there's OTHER METHODS.
Like, tell me to put a file with a long code inside of it, then check it. Y'know, for those guys like me that have rogue ISP's. There's about a half-dozen ways to skin this cat.