Wildcard certs do not work for the AWS route53 provider

[hobosteaux]

What version of sewer are you using?

0.8.1

What did you do? (be as detailed as you can)

Instantiated a client with the following parameters:

client = sewer.Client(
    domain_name="*.test.domain.com",
    dns_class=sewer.Route53Dns(),
    account_key= ...
)

What did you expect to see/happen/not happen?

The cert to be created

What did you actually see/happen?

The TXT record was created under _acme-challenge.*.test.domain.com, but the challenge was looking for it under _acme-challenge.test.domain.com.

Paste here the log output generated by sewer, if any. Please remember to remove any sensitive items from the log before pasting here.

If you can, run sewer with loglevel set to debug; eg sewer --loglevel DEBUG

get_identifier_authorization_success. identifier_auth={'domain': '*.test.domain.com', 'url': '<snip>', 'wildcard': True, 'dns_token': '<snip>', 'dns_challenge_url': '<snip>'}
check_authorization_status_response. status_code=200. response={'identifier': {'type': 'dns', 'value': 'test.domain.com'}, 'status': 'invalid', 'expires': '2020-04-13T23:36:27Z', 'challenges': [{'type': 'dns-01', 'status': 'invalid', 'error': {'type': 'urn:ietf:params:acme:error:dns', 'detail': 'DNS problem: NXDOMAIN looking up TXT for _acme-challenge.test.domain.com - check that a DNS record exists for this domain', 'status': 400}, 'url': '<snip>', 'token': '<snip>'}], 'wildcard': True}

[mmaney]

I think this is a known problem, though I can only find a slightly different wildcard cert problem right now - #91. I'm working on changes that should make it possible to solve 91's issue, and I think I see the cause of your problem. Unfortunately, the easy & obvious fix in client.py might not work properly with other providers that have already taken care of it, so that will have to be checked. Are you comfortable pulling a git tree for testing, Eric? If so I'll setup a branch with the looks-trivial-from-here fix for you to test.

[mmaney]

I knew I'd come across something like this before. Two closed bugs, #102 and #134. Sadly, the first of these suggests that some dns drivers might currently need the * to flag wildcard requests (and makes it clear that others do not want it at all).

[mmaney]

@hobosteaux see PR #163 - the only part that affects route53 are the two lines of code removed from client.py.

[mmaney]

tl;dr: commited PR #163 which fixes the extra star problem, but leaves the service-provider dependent issues when the cert lists both domain and *.domain (see #91 for the latter - it is not unique to route53, alas). The rest of this is details for the record.

After reviewing all the in-tree DNS drivers, I found exactly none that need "*." stuck back onto the domain_name. A fair number did the removal incorrectly, usually by doing so when adding a record but forgetting to do so when removing it. #134 is an example of this that was patched recently. And two, route53 and powerdns, had no de-starring and so fell over when handed a wildcard (this bug and from a discussion with @kylejohnson).

There is a related but separate issue that's shown up a few times, eg. #91, #123 and maybe others. And unless there's a fix I don't see having landed here, eliminating the "*." issue will only expose the underlying problem described in #91. @AirbornePorcine, are you still using this? Have any code you can share, since I don't use route53 and have no great desire to pour over Yet More Sketchy Docs just to produce untested code. :-(

[hobosteaux]

Sorry for the long turnaround time - I tested this by cherry-picking f3eee58 onto 0.8.1, and everything worked fine with wildcards on r53.