Certbot Challenge failed

Help
1

My domain is: 2.node.paultje52.me

I ran this command: certbot certonly --nginx -d 2.node.pautje52.me

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for 2.node.pautje52.me
Using default address 80 for authentication.
Waiting for verification...
Challenge failed for domain 2.node.pautje52.me
http-01 challenge for 2.node.pautje52.me
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: 2.node.pautje52.me
    Type: dns
    Detail: DNS problem: NXDOMAIN looking up A for 2.node.pautje52.me -
    check that a DNS record exists for this domain; DNS problem:
    NXDOMAIN looking up AAAA for 2.node.pautje52.me - check that a DNS
    record exists for this domain

My web server is (include version): NGINX nginx/1.18.0 (Ubuntu)

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

My hosting provider, if applicable, is: (home server)

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

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No, I'm using SSH (in sudo bash).

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

A couple days ago, I used a VPS to generate a ssl certificate for 1.node.paultje52.me in the exact same way. That worked without any problems and I'm enjoying my ssl certificate there :slight_smile:
The only thing that I can think of that is different is that my server is connected to an unifi USG that is in turn connected to the internet. But ports 22, 80 and 443 are forwareded and work without any problems.

I also tried the following steps.

  • Port 80 and 443 are forwarded to my server (I can access websites on my server using my browser)
  • Cloudflare is set to DNS only (not proxied)
  • I've waited for two days to make sure nothing is cached (even though I didn't use the specific subdomain before)
  • Using a manual DNS challenge (using a txt record) also doesn't work
  • Using mxtoolbox.com, the A record are all correct (with my ip, that's also correct)
  • I removed the nginx sites-enabled config, so there aren't any possible conflicts or dropped connections
2

That is not a valid FQDN for a Hostname - Wikipedia; must start with an alpha character.

1 Like
3

And Let's Debug yields a Fatal for the HTTP-01 Challenge
https://letsdebug.net/2.node.pautje52.me/1407861

NoRecords
Fatal
No valid A or AAAA records could be ultimately resolved for 2.node.pautje52.me. This means that Let's Encrypt would not be able to connect to your domain to perform HTTP validation, since it would not know where to connect to.
No A or AAAA records found.
2 Likes
4

Not when I tested there, nor on DNSViz. Just like the message says, the domain name you're trying to get a certificate for doesn't exist.

3 Likes
5

That is an old version of Certbot see Certbot 2.4.0 Release

1 Like
6

I don't think that's the issue here; and numeric-only hostname certificates seem to be a thing. That Wikipedia link references that it was later changed to allow initial numerics in RFC 1123, which was published in 1989. I think systems should have been mostly changed to allow them by now.

4 Likes
7

OK; thanks @petercooperjr :slight_smile:

3 Likes
8

Ah. After enabling one of my nginx sites, letsdebug says everything looks fine again. Howerver, it still says challenge failed.

2 Likes
9

Yes, because I did the same thing for 1.node.paultje52.me and that worked fine

10

Someone on Discord just said that they spotted a typo. I used 2.node.pautje52.me, but it's 2.node.paultje52.me. Sorry everyone :frowning:

3 Likes
11

Here is a list of issued certificates crt.sh | paultje52.me and 1.node.paultje52.me is in the list.

1 Like
12

Have these changed?
RFC 1034 - Domain names - concepts and facilities and RFC 1035 - Domain names - implementation and specification 

<domain> ::= <subdomain> | " "

<subdomain> ::= <label> | <subdomain> "." <label>

<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig-hyp> ::= <let-dig> | "-"

<let-dig> ::= <letter> | <digit>

<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case

<digit> ::= any one of the ten digits 0 through 9
1 Like
13

Yup.

The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax.

4 Likes
14

I didn't realize that RFC 1123 supersedes RFC 1034 and RFC 1035. I had thought that RFC 1123 was specific to hosts; so it applies to Domain Names as well.

1 Like
15

I'm far from being an RFC expert, or maybe there are more documents making things clearer; I was just following the references from the Wikipedia article that Bruce linked. That, and there seem to be plenty of all-numeric domain names out there that seem to work fine. The .xyz TLD was even offering discounted pricing on many all-numeric names at some point (don't know if they still are).

4 Likes
16

Thank you. :smile:

1 Like
17

Well, hostnames & DNS are pretty intertwined and there are 93 references to "DNS" in RFC 1123 (did not check all if applicable to "DNS" or just coincidentally those three letters after one of each other), so I'm preeeeetty sure RFC 1123 also counts for the domain name system, which duty primarily is resolving hostnames :stuck_out_tongue:

3 Likes
18

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