Creating a cert for a private system using route53 plugin

wmuriithi · May 15, 2022, 10:34am

Morning

I ran this command: certbot certonly --dns-route53 --dns-route53-propagation-seconds 60 -d mail.eng.perasotech.com -vvvvvvvv

It produced this output:
host;x-amz-date
e7de089c1250ac45465a71bf0729539b7c79ad8aaaf0e67a5dad2afd481ffca9
StringToSign:
AWS4-HMAC-SHA256
20220515T103259Z
20220515/us-east-1/route53/aws4_request
8cc65f227b12b2e126667664d1ba5bba301f4f0e4fe3e89c018a2f3911ccb52c
Signature:
8c0ff982ed104beb5ef8901a630cc979fdb6640ee7fea96fc689987fda9746c8
Sending http request: <AWSPreparedRequest stream_output=False, method=POST, url=https://route53.amazonaws.com/2013-04-01/hostedzone/Z0047778MD6V91OJIA2H/rrset/, 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'}>
https://route53.amazonaws.com:443 "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/main.py", line 19, in main
return internal_main.main(cli_args)
File "/usr/lib/python3.6/site-packages/certbot/_internal/main.py", line 1632, in main
return config.func(config, plugins)
File "/usr/lib/python3.6/site-packages/certbot/_internal/main.py", line 1491, in certonly
lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
File "/usr/lib/python3.6/site-packages/certbot/_internal/main.py", 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/client.py", line 496, in obtain_and_enroll_certificate
cert, chain, key, _ = self.obtain_certificate(domains)
File "/usr/lib/python3.6/site-packages/certbot/_internal/client.py", line 424, in obtain_certificate
orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
File "/usr/lib/python3.6/site-packages/certbot/_internal/client.py", 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/auth_handler.py", line 105, in handle_authorizations
self._poll_authorizations(authzrs, max_retries, best_effort)
File "/usr/lib/python3.6/site-packages/certbot/_internal/auth_handler.py", 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 https://community.letsencrypt.org. 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

rg305 · May 16, 2022, 2:35am

Hi @wmuriithi, and welcome to the LE community forum

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.
OR
You could wait for a more qualified answer from those that might be more familiar with route53, but are away for the weekend

rg305 · May 16, 2022, 2:37am

I find this confusing:

wmuriithi · May 16, 2022, 9:48am

@rg305

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

wmuriithi · May 16, 2022, 9:49am

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

wmuriithi · May 16, 2022, 9:53am

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

rmbolger · May 16, 2022, 4:26pm

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 perasotech.com:

ns-269.awsdns-33.com.
ns-822.awsdns-38.net.
ns-1268.awsdns-30.org.
ns-1806.awsdns-33.co.uk.

wmuriithi · May 16, 2022, 4:53pm

@rmbolger

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, eng.perasotech.com and perasotech.com. I am seeing the txt file entry created under eng.perasotech.com

Would these zone setup be problematic?

Regards,
William

rmbolger · May 16, 2022, 5:21pm

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 (dyn.example.com is my parent and test.dyn.example.com 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.

rg305 · May 16, 2022, 5:33pm

You must have missed that line.

system · June 15, 2022, 5:33pm

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