"unauthorized" while using Route 53 plugin

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy and only makes it harder for us to provide help.

My domain is: moden.uno, *.moden.uno

I ran this command: sudo certbot certonly -v --dns-route53 -i nginx -d moden.uno -d *.moden.uno --test-cert --break-my-certs

(Note: I use --break-my-certs only because --test-cert requires it.)

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Credentials found in config file: ~/.aws/config
Plugins selected: Authenticator dns-route53, Installer nginx

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
You have an existing certificate that contains a portion of the domains you
requested (ref: /etc/letsencrypt/renewal/moden.uno.conf)

It contains these names: moden.uno

You requested these names for the new certificate: moden.uno, *.moden.uno.

Do you want to expand and replace this existing certificate with the new
certificate?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(E)xpand/(C)ancel: e
Renewing an existing certificate for moden.uno and *.moden.uno
Performing the following challenges:
dns-01 challenge for moden.uno
dns-01 challenge for moden.uno
Waiting for verification...
Challenge failed for domain moden.uno
Challenge failed for domain moden.uno
dns-01 challenge for moden.uno
dns-01 challenge for moden.uno

Certbot failed to authenticate some domains (authenticator: dns-route53). The Certificate Authority reported these problems:
  Domain: moden.uno
  Type:   unauthorized
  Detail: No TXT record found at _acme-challenge.moden.uno

  Domain: moden.uno
  Type:   unauthorized
  Detail: No TXT record found at _acme-challenge.moden.uno

Hint: The Certificate Authority failed to verify the DNS TXT records created by --dns-route53. Ensure the above domains have their DNS hosted by AWS Route53.

Cleaning up challenges
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.

(Note: The redundant dns-01 challenge for moden.uno only happens when I use --test-cert)

My web server is (include version): nginx/1.22.1

The operating system my web server runs on is (include version): Debian 12

My hosting provider, if applicable, is: Route 53 pointing to a Lightsail instance.

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

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

Comments: Hello! I have followed and double checked the instructions on the certbot website, here. I have also checked that the certbot process has a proper AWS IAM user, permissions, and credentials, as a different error occurs if any are wrong. I have also verified that the TXT record/s are created on Route 53; I am not sure how or why the above error types are "unauthorized."

I can check Route 53 and see that the TXT record is added when certbot runs (and removed when certbot finishes), but external investigation has never shown the record. The certbot process errors-out after about 30 seconds, but I have never had a record propagate on Route 53 within that time. I have a feeling that the record is not being given time to propagate, but the --dns-route53-propagation-seconds argument has been deprecated.

I appreciate any feedback the community may have and am more than happy to answer any questions.

2

Welcome to the community @modenuno

Let's Encrypt will cache successful authentications but otherwise you should see two challenges when requesting a wildcard cert with the root name and a wildcard for it.

I suggest using --dry-run instead of --test-cert --break-my-certs. The --dry-run will invalidate any cached auths, uses the LE staging system, but will not break any existing certs.

I am pretty sure the LightSail "Route53" is not quite the same as the native Route53 API. The Certbot plugin only supports the native Route53 API. I can't easily find the references and maybe Lightsail now uses the native Route53. But, at least fairly recently (in past year) they were different.

If you make changes to the DNS using the AWS Console, do you use the Lightsail panel or Route53 itself?

I am puzzled by this comment. If you can't see the TXT record from the public internet then Let's Encrypt servers won't find it. How are you verifying it otherwise?

The https://unboundtest.com site is a good way to query the DNS similar to how LE does it.

The Certbot plugin now checks whether the change was reported as "InSync" and so does not need to wait a predefined number of seconds. I don't use that plugin but I use the same Route53 api and typically I get InSync in about 30-40s.

There is a --debug-challenges option which should pause after the TXT records are placed but before submitting to LE. I am not certain it works with Route53 plugin but it should. You might try that to give you more time to check from unboundtest

5 Likes
3

Thank you!

Will do.

I've been using the Route 53 interface but had also added domain information to Lightsail. It is likely what was causing my issue.

I was running certbot, reloading the Route 53 UI, and seeing that certbot's TXT record had been created. I would then run an nslookup of the domain to not find the record. It was boneheaded of me to not add my own TXT record and verify that it came through externally, though.

While doing some more testing while reading your response, MikeMcQ, I noticed that the NS records I got from DNS lookups did not match those in Route 53.

I am fairly certain that the issue was that I had entered domain information in Lightsail and later, trying to use certbot, found out that AWS's DNS is (generally) Route 53. I set up a hosted zone, IAM permissions, etc. and didn't consider how my site's DNS had worked before I set up the Route 53 hosted zone.

While writing this response, I was able to fix the issue in that I was able to dry run successfully. I will write out the steps I took below.

If you've started a Lightsail instance, given it a static IP, have a domain registered within Route 53, and want to use certbot to add https (especially for wildcard support!):

  1. On the Lightsail instance, delete all domain information, if any.
  2. In Route 53, if a hosted zone for the domain exists, delete the domain's hosted zone. (I am not sure if this is necessary but it is what I did.)
  3. Create a Route 53 hosted zone for the domain.
  4. In the hosted zone, create records that route to the Lightsail instance static public IP. (I created simple routing policies for moden.uno and *.moden.uno that both point to my Lightsail instance's IP.)
  5. From the hosted zone, copy or take note of the NS record's values or keep the tab open.
  6. In Route 53, open Domains -> Registered domains and click on the domain in question.
  7. Open the name server editor by clicking Actions -> Edit name servers
  8. Replace the name server values with the values provided from the hosted zone's NS record and save the changes.

After waiting for a little while, external DNS queries matched the new name servers and I was able to dry run certbot successfully.

If anyone reading this is considering using Lightsail as a VPS to host a domain/website, I would suggest not using Lightsail's built-in domain/DNS handling. Using Route 53 gives you more control, isn't difficult to set up, and the certbot plugin for Route 53 is current.

1 Like
4

Glad I could help.

I think the AWS docs for pointing Route53 at Lightsail is here

2 Likes
5

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