Certbot --dry-run --manual-auth-hook failure


#1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
tor-ns8ds.com

I ran this command:
certbot certonly --manual -d ‘*.tor-ns8ds.com’ -d tor-ns8ds.com --preferred-challenges dns-01 --dry-run --manual-auth-hook ./plugin.sh

It produced this output:
Failed authorization procedure. tor-ns8ds.com (dns-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect TXT record “4uqZprjIo0sN852JlcNjqBS-La764UM7_mPfXehXHxI” (and 1 more) found at _acme-challenge.tor-ns8ds.com

My web server is (include version):
nginx 1.10.3

The operating system my web server runs on is (include version):
Ubuntu 16.04

My hosting provider, if applicable, is:
N/A

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):
no


Some backstory…

I am currently developing a script to be used with the --manual-auth-hook option. Because the certificate has both the domain and the wildcard domain, the script gets called twice with a separate validation token for each. The script handles this accordingly, such that it remembers the token from the first time it is called, and the second time it is called, it sets 2 TXT records for _acme-challenge.tor-ns8ds.com, one for each token.

When I setup another domain with the dns01 challenge manually, this is essentially what I did: when it spit out the first token, I immediately hit enter to get the 2nd token, then set the actual DNS record with those tokens before hitting enter again. At that point, the DNS authorization would occur, and everything worked fine.

However, with the --manual-auth-hook option, I can see the script receiving the 2 tokens, then setting the DNS records (verified with dig), but the authorization fails anyway. I’ve tried making the hook script sleep (up to 30s), thinking there might need to be some kind of propagation, but that had no effect.

At this point, the only straw I’ve got to grasp at is some sort of TTL issue with my DNS server. That doesn’t sound like a winner right away, because I had the dns authorization succeed on another domain multiple times in a row (live mode) when I was setting the DNS records the same way and the TTL didn’t cause me an issue there, even though the TTL was much longer than it took me to change the DNS records.

Is it possible I have some incompatible combination of bits that I’m just not seeing? It sure seems like the dns01 authorization should succeed when I can see with my own eyes that the TXT records exist, but I only recently started using certbot, so I could definitely just be missing something obvious.

Either way… thanks for reading this far! Any help is incredibly appreciated! :slight_smile:


#2

Seems like a strange design, but it shouldn’t affect the outcome.

Can you show the script? Can you include direct queries into the script to demonstrate that the records are set?

sleep 30
echo "Set record for ${CERTBOT_DOMAIN} ${CERTBOT_VALIDATION}"
dig +noall +answer @ns.tor-ns8ds.com _acme-challenge.tor-ns8ds.com TXT

#3

Curious as to why you think its a strange design? Certbot issues 2 separate tokens, calling the script once for each token, but doesn’t actually run its authorization routine until after the 2nd token, so my thinking was to only set the records (and reload the zone on the DNS server itself) once, since doing it twice seemed unnecessary. Either way, if there’s a better way to do this, please feel free to share your ideas. I definitely want to go with the best way of doing things.

At one point, I did have a dig and sleep in the script (though the dig was first, then the sleep), and it indeed showed the server displaying the correct records. I’ll go ahead and put the echo’s and digs back in the script and run it, so I can show the output.

I’m not sure just pasting the whole script would be helpful, since there are bits that I know are working as intended (for example: the DNS records go into a mongo db, and our resolver reloads them, and I can verify that is all functional not only by querying mongo directly, but also by digging the DNS server). But the block of code that is run once both tokens have been received looks like this:

#mongo.tmp contains the necessary mongo commands to set the DNS records (mongo auth info omitted here)
mongo < mongo.tmp

#trigger the resolver to reload
resolver reload

#and now, I’ve added:
sleep 30
echo “Set record for ${CERTBOT_DOMAIN} ${TXT1} and ${TXT2}”
dig +noall +answer @ns.tor-ns8ds.com _acme-challenge.tor-ns8ds.com TXT

The output from this last run gave me lead to track down… I’ll update this with what happens with that.

Thanks again!


#4

Cleverness usually has a way of biting us in the ass. If you have concerns about the overhead of a reload, most nameservers provide a way to reload only a single zone.


#5

So, it turns out my experience with running manual mode before was what got me tripped me up here.

Like I mentioned, when I ran this process manually, I would let certbot spit out both tokens before changing any of the DNS records, then after hitting enter on that 2nd token, certbot would perform the validation and everything was fine.

Re-reading the certbot documentation super closely on the hooks, it clearly says that the auth hook is run, validation is performed, and then the cleanup hook is run. Because of this, the method of updating both records at once just wasn’t going to work.

Long story even longer, a few modifications to the script so that it updates the records individually, and the dry run is successful now.

Thanks again for your help!


#6

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