I might have discovered a minor bug in Certify v4 - When requesting a wildcard certificate and Authorization DNS Custom Script there is a difference in the “Target Domain” that’s sent to my external script between Test and Request
Certificate Domains:
*.example.com
Authoization Setting:
Challenge Type: dns-01
DNS update method: Use Custom Script
Test sends: example.com _acme-challenge-test.example.com abcd123
Request sends: *.example.com _acme-challenge.example.com abcd123
It’s easy to work around by only using the “Record Name” but it caught me out first time!
It seems to be okay with non wildcard so is this by design or a bug?
Thanks for pointing that out - oops that behavior could be tricky to change now that it’s out in the wild. Yes the test and non-test version should have different prefixes (_acme-challenge and _acme-challenge-test) but there shouldn’t have been a difference in having the wildcard string passed through as the ‘domain’.
Probably we should be stripping the *. from the start as we do in the Test mode, but it’s debatable. Interestingly nobody else has raised that as an issue.
Originally DNS validation was non-wildcard but now that it’s also used for wildcards the actual operation it performs is still on the same TXT record whether the request is wildcard related or not (this is a Let’s Encrypt restriction). So a workaround is to strip the *. from the domain if you are using that as a lookup in your script.
I actually prefer using the optional fourth parameter (zoneid) as a way of identifying the correct zone to update as there are a couple of situations that can catch you out when matching zones on domain strings only.
I was also wondering what the zoneid parameter actually did? I’m guessing some DNS API’s only as it doesn’t get passed to the custom DNS script - should it?
For some DNS API’s your zoneid would just be the parent domain like ‘example.com’, but for other’s its an Id like a number or a GUID/string (like AWS Route53). In the app we provide a dropdown to make zoneid selection easy (for automated DSN APIs) and that avoids any further errors identifying the correct zone (in theory!).
We should definitely make it so the zone textbox isn’t shown if the API doesn’t use it, however all DNS providers I’ve encountered should have a use for that (GoDaddy is an awkward one but it still has zones but it calls them domains, and the zoneid is not being used properly).
The zoneid should be being passed to the custom script (it is optional though), so it’s a bug if it’s not.