Creating a cert for a private system using route53 plugin


My domain is:

I ran this command: certbot certonly --dns-route53 --dns-route53-propagation-seconds 60 -d -vvvvvvvv

It produced this output:
Sending http request: <AWSPreparedRequest stream_output=False, method=POST, url=, headers={'User-Agent': b'Boto3/1.15.15 Python/3.6.8 Linux/4.18.0-348.12.2.el8_5.x86_64 Botocore/1.18.15', 'X-Amz-Date': b'20220515T103259Z', 'Authorization': b'AWS4-HMAC-SHA256 Credential=AKIA3EL63BWMME2O5RBJ/20220515/us-east-1/route53/aws4_request, SignedHeaders=host;x-amz-date, Signature=8c0ff982ed104beb5ef8901a630cc979fdb6640ee7fea96fc689987fda9746c8', 'Content-Length': '523'}> "POST /2013-04-01/hostedzone/Z0047778MD6V91OJIA2H/rrset/ HTTP/1.1" 200 351
Response headers: {'x-amzn-RequestId': 'ab4d1ca3-f9a0-42e7-8a32-1bcf4e173d68', 'Content-Type': 'text/xml', 'Content-Length': '351', 'Date': 'Sun, 15 May 2022 10:32:58 GMT'}
Response body:
b'<?xml version="1.0"?>\n/change/C09114472U2FQ8L68X7FLPENDING2022-05-15T10:32:59.413Zcertbot-dns-route53 certificate validation DELETE'
Event needs-retry.route-53.ChangeResourceRecordSets: calling handler <botocore.retryhandler.RetryHandler object at 0x7f61224082e8>
No retry needed.
Exiting abnormally:
Traceback (most recent call last):
File "/usr/bin/certbot", line 11, in
load_entry_point('certbot==1.22.0', 'console_scripts', 'certbot')()
File "/usr/lib/python3.6/site-packages/certbot/", line 19, in main
return internal_main.main(cli_args)
File "/usr/lib/python3.6/site-packages/certbot/_internal/", line 1632, in main
return config.func(config, plugins)
File "/usr/lib/python3.6/site-packages/certbot/_internal/", line 1491, in certonly
lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
File "/usr/lib/python3.6/site-packages/certbot/_internal/", line 139, in _get_and_save_cert
lineage = le_client.obtain_and_enroll_certificate(domains, certname)
File "/usr/lib/python3.6/site-packages/certbot/_internal/", line 496, in obtain_and_enroll_certificate
cert, chain, key, _ = self.obtain_certificate(domains)
File "/usr/lib/python3.6/site-packages/certbot/_internal/", line 424, in obtain_certificate
orderr = self._get_order_and_authorizations(, self.config.allow_subset_of_names)
File "/usr/lib/python3.6/site-packages/certbot/_internal/", line 476, in _get_order_and_authorizations
authzr = self.auth_handler.handle_authorizations(orderr, self.config, best_effort)
File "/usr/lib/python3.6/site-packages/certbot/_internal/", line 105, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, best_effort)
File "/usr/lib/python3.6/site-packages/certbot/_internal/", line 205, in _poll_authorizations
raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.
Some challenges have failed.
Ask for help or search for solutions at See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details

My web server is (include version): N/A

The operating system my web server runs on is (include version): Rocky Linux release 8.5 (Green Obsidian)

My hosting provider, if applicable, is: Self hosted, but have tried on AWS with same results

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): N/A

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

Hi @wmuriithi, and welcome to the LE community forum :slight_smile:

I'm not familiar with AWS nor route53...
But I would try increase the 60 seconds to 300 [just to test].
And if that has no effect, I would try creating the "mail.eng" subfolder/subdomain, and then try it again.
You could wait for a more qualified answer from those that might be more familiar with route53, but are away for the weekend :wink:

1 Like

I find this confusing:

1 Like


Its indeed confusing. I didn't know what to make of it, but assumed its expected as I have seem to on google when others are discussing certbot issues

Increased the timeout to 300 as suggested. No difference, still failed

  • Initially, I had assumed its permissions to make change on Route 53 that was a problem. I then watched the DNS entries as the certbot is running and I can see it create the TXT record before it finally remove it at some point later. So I am certain this isn't a permission issue

Quick sanity check. The records are getting created/removed in a Route53 public zone, right? Not a private zone. Specifically, the public zone that matches these NS records which are authoritative for


Thanks for reaching out. Appreciate.

Yes, the text file is being created on Route53 and the zone is public.

Actually, I may need to clarify here, in case this is the root of the problem.

I have two public zones, and I am seeing the txt file entry created under

Would these zone setup be problematic?


1 Like

No, that's totally normal. However, in Route53, I don't think it's as simple as just adding the sub-zone. When I tested doing this on my own account, it didn't automatically create the NS records in the parent zone to point to the sub-zone's nameservers (which are different than the parent zone).

Can you check in your parent zone that there is an NS record set for the root domain and another one for the eng sub-zone?

If the sub-zone one is missing, that's the problem. You'll need to create a new NS record in the parent zone and add the nameservers listed in the sub-zone. Mine looks like this ( is my parent and is my sub).

You'll know it's fixed when this dig query returns your sub-zone nameservers instead of NXDOMAIN.

Dig web interface - online dns lookup tool.


You must have missed that line.

1 Like

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