Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:

Help
1

C012121216R:.oci tempuser$ sudo certbot certonly --manual --preferred-challenges dns -d "poc3-ashburn.tempdev.space"
Password:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for poc3-ashburn.tempdev.space

Please deploy a DNS TXT record under the name:

_acme-challenge.poc3-ashburn.tempdev.space.

with the following value:

j3OkKlhQQmr-sqg4qi_HFxakM-94pXRla0DQsjl86KE

Before continuing, verify the TXT record has been deployed. Depending on the DNS
provider, this may take some time, from a few seconds to multiple minutes. You can
check if it has finished deploying with aid of online tools, such as the Google
Admin Toolbox: Dig (DNS lookup).
Look for one or more bolded line(s) below the line ';ANSWER'. It should show the
value(s) you've just added.

Press Enter to Continue

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: poc3-ashburn.tempdev.space
Type: dns
Detail: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.poc3-ashburn.tempdev.space - check that a DNS record exists for this domain

Hint: The Certificate Authority failed to verify the manually created DNS TXT records. Ensure that you created these in the correct location, or try waiting longer for DNS propagation on the next attempt.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
C012121216R:.oci tempuser$

2

Ok, did you add that txt record? (You actually have to do it yourself, if you use --manual)

4 Likes
3

yes, I have added _acme-challenge under tempdev.space domain

4

Ok, but... it was expected under poc3-ashburn.tempdev.space.

4 Likes
5

Are you on the right DNS system?
There is no TXT record at either path:
nslookup -q=txt _acme-challenge.poc3-ashburn.tempdev.space
nslookup -q=txt _acme-challenge.tempdev.space

3 Likes
6

Not even in the mishmashed paths:

nslookup -q=txt _acme-challenge.poc3-ashburn.tempdev.space.poc3-ashburn.tempdev.space
nslookup -q=txt _acme-challenge.poc3-ashburn.tempdev.space.tempdev.space
nslookup -q=txt _acme-challenge.tempdev.space.tempdev.space
3 Likes
7

Let me explain my problem in detail

  1. We have a domain that was created by my ex-colleague e.g. example.com
  2. He had created the hosted zone (subdomain1.example.com.) in the aws route53 and could generate a certificate with a wildcard.
  3. I have the acme_account_key which was used by the ex-colleague.
  4. I am able to generate certs for suubdomain2.example.com using terraform script
  5. Now we are creating an OCI-hosted zone with subdomain3.example.com, Here it's complaining about txt record not being found.
    Note : we added the record in example.com as subdomain3.example.com,
8

Ok, but the _acme-challenge label needs to go exactly under the fqdn you want to validate.

And, in case it wasn't clear, it needs to go on the public DNS. :smiley:

3 Likes
9

while creating a wild card certificate for [suubdomain2.example.com] using terraform script. I didn't added _acme-challenge but it works

11

Is the subdomain part of the wildcard [ i.e. *.example.com ]
OR contains the wildcard [ i.e. *.subdomain2.example.com ]
?

Then the script did it for you:

But wildcard certs must be validated that way [in DNS].

2 Likes
12

yes . it contains the wildcard [ i.e. *.subdomain2.example.com]

13

OK, that makes sense [now].

The script must be making the TXT record for it, at:
_acme-challenge.subdomain3.example.com
[and it may delete it once it's done]

2 Likes
14 
*.sys.poc3-ashburn.example.com] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: No TXT record found at _acme-challenge.sys.poc3-ashburn.example.com
│ [*.tcp.poc3-ashburn.example.com] acme: error: 403 :: urn:ietf:params:acme:error:unauthorized :: No TXT record found at _acme-challenge.tcp.poc3-ashburn.example.com
│ [poc3-ashburn.example.com] acme: error: 400 :: urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.poc3-ashburn.example.com - check that a DNS record exists for this domain
15

Why does that include "example.com"?
Is that the actual error message?

2 Likes
16

Same script works fine subdomain2 which is the hosted zone in route53 and this is not working for subdomain3 hosted zone present in oci

17

yes above is the actual error

18

OCI?

Did you really try to get a cert for "example.com"?

2 Likes
19

yes. oracle cloud.

20

The terraform script in use may be setup to update ROUTE53.
If this subdomain is served from some other DSP, then you may need to generate a new script.

2 Likes
21

example.com is just an example. Assume one domain xyz.com which is registered using AWS. We are able to create a wildcard for the subdomain.xyz.com hosted zone present in aws rout53. Now we are trying to generate wildcard certs for hosted zone subdomain2.xyz.com present in OCI