I’m using the certbot-auto utility and lexicon via a script from this post to automate renewal of a few of sub-domains:
*.xx.stagingdomain.in
*.yy.stagingdomain.in
*.zz.stagingdomain.in
stagingdomain.in → base domain
*.stagingdomain.in → wildcard domain
While the script runs perfectly fine for the 1st 3 domains (including adding & removing the requisite TXT records for the dns-01 challenge), it fails for the last 2 because:
the TXT record for both the base domain is _acme-challenge.stagingdomain.in
Also, the TXT record for wildcard domain is _acme-challenge.stagingdomain.in
Somehow, the script deletes the TXT record for the base domain before creating a TXT record for the wildcard domain (I’ve understood that both TXT records need to co-exist) thus failing the validation & the SSL renewal with the message.
The client lacks sufficient authorization ::
To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address.
Now, I know a workaround is to manually add those TXT records but for one, it doesn’t help if you’ve multiple domains and when it comes to automating the entire process.
I’ve checked around in the LetsEncrypt forums & I’ve found some similar issues post-1, post-2 and an issue on GitHub here
@schoen, @bmw - I’d greatly appreciate if you guys could please take a moment to weigh in with your recommendations here.
Do let me know if I can provide any more information.
You haven’t mentioned what DNS host you are using, but my general comment is that wrong handling of identical TXT labels is a bug. I know that the Lexicon Route53 provider is currently broken in this specific way, and it’s not be the only one.
@_az I’m using AWS Route53 for my DNS and as much I could check on the LE forums, even I felt it’s a bug.
Also, I was able to publish multiple TXT records for the base domain & wildcard domain, enclosed in inverted quotes & one per line via the Route53 Web Interface - verified as follows:
edge-star-macOSX-vh1:~ vinayhegde$ dig +noall +answer _acme-challenge.stagingdomain.in TXT @8.8.8.8
_acme-challenge.stagingdomain.in. 247 IN TXT "random-hash-token-1"
_acme-challenge.stagingdomain.in. 247 IN TXT "random-hash-token-2"
So could you please help me to achieve any workaround to this or would I have to stop using lexicon altogether for another alternative?
There’s no workaround, sorry (besides heavily rewriting the script). The post was written before wildcards went live (so duplicate labels weren’t a factor) and I retracted the post once it became clear the fix would take a while. Today, I’d suggest to use acme.sh or the Certbot Route53 plugin if you can use the non -auto version of Certbot.
No problem, thanks for the quick response and sharing the fact your script would need a rewrite @_az!
As I mentioned initially, your script does cover wildcard SSL correctly when I run it in a dry-run mode for the 1st three of my domains before I hit this TXT record bug for the next 2 of them.
Quick question - based on a cursory reading of their docs which don’t mention it as such, does the Certbot Route53 plugin for the non -auto version cover wildcard SSL?
Ok, I shall explore both acme.sh & the Certbot Route53 plugin (the former looks easier to understand, implement & maintain). Shall keep this post updated if I’d need any help, please don’t mind.
Thanks again @_az & @schoen, you’ve been of great help!!
Hi @mnordhoff, I’m using Ubuntu 16.04 LTS and from the documentation of Certbot Route53 plugin, I concur with you to a large extent.
This is because it needs certbot to be installed via a PPA which depends on python3 and an erroneous command like apt-get upgrade later could break a whole lot of stuff (for certbot itself & other projects that use python3).
They could be fixed via pip, package managers and virtualENVs but it’d be an additional overhead and we may end up creating more problems than resolve.