I was running into problems with validation of certs that have both Base + Wildcard (
*.example.com). I finally solved the issue but I that unearthed some problems/flaws in the process for me.
The DNS auth for this certificate will require checking two TXT records for the same key:
_acme-challenge.example.com= first record
_acme-challenge.example.com= second record
Unfortunately, these keys are not set at the same time. Because there may be caches and proxy servers anywhere in between the DNS vendor and LE,
boulder querying the first record seems to have triggered a cache somewhere for the
_acme-challenge which needed an excessive time to expire.
After a lot of experimenting, the fix was:
- update the script generated by @_az’s blog post to pass in a 60s TTL to my
- update the
lexiconprovider to respect the TTL (it was not used by that provider, in fact several ignore it)
- update _az’s script again to use a 120s sleep after creating the certificate (expecting a local and middleman proxy to both stall the process). nothing slower worked for me.
IMHO, requiring two
_acme-challenge keys on the same domain, inserted serially, is a flaw in this process because of caching concerns. It would be great if they had different names, were created in parallel, or only one key was needed.
Somewhere in there I also deleted the cleanup hook that _az had, as it seemed the cleanup step may have been an issue (it wasn’t, but I’ve still removed it)
Which brings me to my second point/potential flaw - when things go wrong (and LOTS of things went wrong while testing) it’s not possible to tell which of the challenge TXT records are safe to delete. It would be great if the record values allowed users to append a timestamp or something to the value. For example, instead of boulder looking for an exact 43char string, it could look at the first 43 chars of the string. This would users append some internal validation info into the record.