Wildcard Certificate creation error

Help
1

Please fill out the fields below so we can help you better.

My domain is: I prefer not to mention for security reasons

I ran this command: certbot certonly --dns-route53 -d $DOMAIN -d *.DOMAIN --agree-tos -n

It produced this output:

Type: dns
Detail: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.DOMAIN - check that a DNS record exists for this domain

Hint: The Certificate Authority failed to verify the DNS TXT records created by --dns-route53. Ensure the above domains are hosted by this DNS provider, or try increasing --dns-route53-propagation-seconds (currently 10 seconds).

Some challenges have failed.
Type: dns
Detail: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.DOMAIN - check that a DNS record exists for this domain

Hint: The Certificate Authority failed to verify the DNS TXT records created by --dns-route53. Ensure the above domains are hosted by this DNS provider, or try increasing --dns-route53-propagation-seconds (currently 10 seconds).

Some challenges have failed.

My hosting provider, if applicable, is: route53

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Being tested with 0.40 and 2.4

I have already installed certbot and dns-route-53 plugin, the keys of aws are correct and policies etc associated are correct too as it doesn't complain about this anymore (if it is a permission issue there is an error message that says it)
certbot and dns-route53 plugin look ok. I just don't understand what the acme challenge error means and to which txt is referring too. This with other domains that are not the main wildcard was working perfectly and i was able to create certificates, but with this wildcard domain I am facing the issue mentioned above. I did a lot of testing, but not sure what is about exactly.

Thank you for your help
guille

1 Like
2

The error message seems pretty clear to me.
Does any TXT record exist there?
[there should be two of them]

Is $DOMAIN a long FQDN [a domain name with subdomains]?

2 Likes
3

OR
Maybe it is literally just a TYPO.

If this is the exact line used:

As shown, what is?
*.DOMAIN

That should be:
*.$DOMAIN

3 Likes
4

Thank you rg305 thank you for your comment, i believe it is not a typo, just i don't understand what is the txt record for letsencrypt is it refering to the record in route53 because is already there since. My confusion is that i don't understand the acme_challenge what it means and where the txt record is located which is trying to read.

I confirm the TXT record is in route53 and the naming in the command is correct. In regards to the acme_challenge message I don't know what it means either _acme-challenge.DOMAIN

Do you know where is trying to find it? I thought it had to find it in Route53 with the --dns-route53 flag.
Thank you for your help
guille

1 Like
5

Without the actual domain name there is little we can do.

You can use https://unboundtest.com to lookup the TXT record yourself. It uses the same a very similar method as Let's Encrypt servers.

On that screen select TXT record and the DNS record name will be _acme-challenge.example.com with of course your domain instead

Also visit dnsviz.net to look for DNS config problems. Sometimes people mix up their DNS name server chain

3 Likes
6

Please see DNS-01 challenge of the Challenge Types - Let's Encrypt

2 Likes
7

What security reason?

The questionnaire (the part you've removed anyway) is quite simple: no domain, no help.

3 Likes
8

Thanks a lot for your comments, now I have a better picture of the acme challenge. The question that I have is why is asking this and not for other domains that I have used with letsencrypt?

It is certain that domain I am trying to create the ssl certificate is associated with different route53 accounts, which means I have been using it with dns route53 DOMAIN1 in different accounts, but I guess it shouldn't matter if the AWS keys are pointing to the correct account that I am trying to use the SSL certificate.

Also something that is interesting to me is why is trying to use the DNS-01 challenge I am indicating this in the command without being pretty certain of it? (That it could be) Just I used these command for previous domains and the challenge wasn't an issue.

######## About part of the txt record response I have got the following information below:
----- Unbound logs -----
Mar 17 13:15:18 unbound[747700:0] notice: init module 0: validator
Mar 17 13:15:18 unbound[747700:0] notice: init module 1: iterator
Mar 17 13:15:18 unbound[747700:0] info: start of service (unbound 1.16.3).
Mar 17 13:15:18 unbound[747700:0] info: resolving . DNSKEY IN
Mar 17 13:15:18 unbound[747700:0] info: priming . IN NS
Mar 17 13:15:18 unbound[747700:0] info: response for . NS IN
Mar 17 13:15:18 unbound[747700:0] info: reply from <.> x.x.x.x53
Mar 17 13:15:18 unbound[747700:0] info: query response was ANSWER
Mar 17 13:15:18 unbound[747700:0] info: priming successful for . NS IN
Mar 17 13:15:18 unbound[747700:0] info: response for . DNSKEY IN
Mar 17 13:15:18 unbound[747700:0] info: reply from <.> x.x.x.x#53
Mar 17 13:15:18 unbound[747700:0] info: query response was ANSWER
Mar 17 13:15:18 unbound[747700:0] info: prime trust anchor
Mar 17 13:15:18 unbound[747700:0] info: generate keytag query _ta-4f66. NULL IN
Mar 17 13:15:18 unbound[747700:0] info: resolving . DNSKEY IN
Mar 17 13:15:18 unbound[747700:0] info: validate keys with anchor(DS): sec_status_secure
Mar 17 13:15:18 unbound[747700:0] info: Successfully primed trust anchor . DNSKEY IN
Mar 17 13:15:18 unbound[747700:0] info: resolving _ta-4f66. NULL IN
Mar 17 13:15:18 unbound[747700:0] info: validate(positive): sec_status_secure
Mar 17 13:15:18 unbound[747700:0] info: validation success . DNSKEY IN
Mar 17 13:15:18 unbound[747700:0] info: response for _ta-4f66. NULL IN
Mar 17 13:15:18 unbound[747700:0] info: reply from <.> x.x.x.x#53
Mar 17 13:15:18 unbound[747700:0] info: query response was NXDOMAIN ANSWER

Mar 17 13:15:19 unbound[747700:0] info: query response was ANSWER
Mar 17 13:15:19 unbound[747700:0] info: response for io. DNSKEY IN
Mar 17 13:15:19 unbound[747700:0] info: reply from <io.> 2a01:8840:a1::17#53
Mar 17 13:15:19 unbound[747700:0] info: query response was ANSWER
Mar 17 13:15:19 unbound[747700:0] info: validated DNSKEY io. DNSKEY IN
Mar 17 13:15:19 unbound[747700:0] info: validated DNSKEY io. DNSKEY IN
Mar 17 13:15:19 unbound[747700:0] info: resolving DOMAIN. DS IN
Mar 17 13:15:19 unbound[747700:0] info: response for ns-.awsdns-.com. AAAA IN
Mar 17 13:15:19 unbound[747700:0] info: reply from <awsdns-*.com.> 2600:9000:5300:2700::1#53
Mar 17 13:15:19 unbound[747700:0] info: query response was ANSWER
Mar 17 13:15:19 unbound[747700:0] info: response for $DOMAIN. DS IN
Mar 17 13:15:19 unbound[747700:0] info: reply from <io.> Y.Y.Y.Y#53
Mar 17 13:15:19 unbound[747700:0] info: query response was nodata ANSWER
Mar 17 13:15:19 unbound[747700:0] info: NSEC3s for the referral proved no DS.
Mar 17 13:15:19 unbound[747700:0] info: NSEC3s for the referral proved no DS.
Mar 17 13:15:19 unbound[747700:0] info: Verified that unsigned response is INSECURE
Mar 17 13:15:19 unbound[747700:0] info: Verified that unsigned response is INSECURE

What you would recommend me to do in the dns server?

Thank you for your help
Guille

9

You requested a certonly using the DNS Challenge with Route53.

Your numerous redactions have only confused this issue. For example, in your command you have $DOMAIN and *.DOMAIN (no $). You won't be able to get a cert for the exact domain name DOMAIN.

In that latest post you now call it DOMAIN1

I have worked on numerous problems like this. If you understood all that is happening you wouldn't need our help.

Please share your actual domain name. I or another experienced volunteer will be able to give specific advice to resolve the underlying problem.

3 Likes
10

Thank you Mike I confirm the problem is not related with the command itself.
certbot certonly --dns-route53 -d $DOMAIN -d *.$DOMAIN --agree-tos -n

1 Like
11

OK. But problem remains. You asked what to do in DNS server ... You select which ones you use in the Route53 panel but you cannot do anything in the DNS server itself (it belongs to AWS).

Without the actual domain name I will not be commenting further. I wish you good luck

3 Likes
12

Hi Mike thank you for your comments and appologies for not bringing the domain name to the ticket.
The domain name is immerse.io

Let me know if it is anything else that I can provide.
Thanks a lot,
Guille

1 Like
13

Can you run Certbot again with the added option --debug-challenges? And keep Certbot paused for volunteers to debug?

3 Likes
14

Hello Osiris, I have got the following messages after running the command in debug mode:

Plugins selected: Authenticator dns-route53, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for immerse.io
dns-01 challenge for immerse.io
Waiting for verification...

Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.

Challenge failed for domain immerse.io
Challenge failed for domain immerse.io
dns-01 challenge for immerse.io
dns-01 challenge for immerse.io
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: immerse.io
    Type: dns
    Detail: DNS problem: NXDOMAIN looking up TXT for
    _acme-challenge.immerse.io - check that a DNS record exists for
    this domain

    Domain: immerse.io
    Type: dns
    Detail: DNS problem: NXDOMAIN looking up TXT for
    _acme-challenge.immerse.io - check that a DNS record exists for
    this domain

About pausing it, how it would do that step, if there is any additional flag let me know, I cannot see it in the generic help at first glance.

Thank you for your help,
Guille

1 Like
15

When it says this: Do not "press continue". Just let us know when you have that prompt and we can check the DNS. Thanks

4 Likes
16

I suggest that testing and debugging are best done using the Staging Environment as the Rate Limits are much higher.

https://tools.letsdebug.net/cert-search?m=domain&q=immerse.io&d=168 is showing

Rate Limit Current Status Domain
50 Certificates per Registered Domain per week OK (5 / 50 this week.) immerse.io
Summary generated at letsdebug-toolkit .

image
image822×277 3.84 KB

1 Like
17

Thank you for all we are getting there : -)
Ok I confirm that I didn't press enter to continue is waiting now to my "Intro" key

Challenges loaded. Press continue to submit to CA. Pass "-v" for more info about
challenges.

Press Enter to Continue

I hope it helps,
Thanks a lot,
guille

2 Likes
18

Hmmm. The TXT record is definitely not there. And, I don't see it in other locations where we sometimes see these placed by mistake. You can see for yourself with unboundtest.com tool I linked earlier:
https://unboundtest.com/m/TXT/_acme-challenge.immerse.io/XPYS4ABC

Are you sure your AWS security credentials allow changes at this level of your domain? I see in your cert history you recently got wildcard Let's Encrypt certs for subdomains of this name (link here) ? Review docs here:
https://certbot-dns-route53.readthedocs.io/en/stable/

If you think that is correct then maybe the log will show info. Make a copy of /var/log/letsencrypt/letsencrypt.log to a .txt file and use the upload file button in this post menu

3 Likes
19

That is quite very good piece of information. It is giving an authorization error for a hosted zone, but surprisingly the policy has the zones, the permissions and the user has it. I think I am going through the rabbit hole with this

{
"Version": "2012-10-17",
"Id": "certbot-dns-route53 sample policy",
"Statement": [
{
"Effect": "Allow",
"Action": [
"route53:ListHostedZones",
"route53:GetChange"

and the hosted zone needed is there.

This is the piece of log after executing the command. I decided to use my dev env in aws and to follow your advice.

Traceback (most recent call last):
File "/usr/bin/certbot", line 11, in
load_entry_point('certbot==0.40.0', 'console_scripts', 'certbot')()
File "/usr/lib/python3/dist-packages/certbot/main.py", line 1382, in main
return config.func(config, plugins)
File "/usr/lib/python3/dist-packages/certbot/main.py", line 1265, in certonly
lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
File "/usr/lib/python3/dist-packages/certbot/main.py", line 121, in _get_and_save_cert
lineage = le_client.obtain_and_enroll_certificate(domains, certname)
File "/usr/lib/python3/dist-packages/certbot/client.py", line 417, in obtain_and_enroll_certificate
cert, chain, key, _ = self.obtain_certificate(domains)
File "/usr/lib/python3/dist-packages/certbot/client.py", line 348, in obtain_certificate
orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
File "/usr/lib/python3/dist-packages/certbot/client.py", line 396, in _get_order_and_authorizations
authzr = self.auth_handler.handle_authorizations(orderr, best_effort)
File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 91, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, best_effort)
File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 180, in _poll_authorizations
raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.

I confirm the policy you mentioned I used previously for other domains with no issues and contains the hosted zones needed: Welcome to certbot-dns-route53’s documentation! — certbot-dns-route53 0 documentation

Not sure what could be next step if the policy and user look good. :confused:

Thanks a lot,
Guille

1 Like
20

That could use an update.

2 Likes