Certbot returning a different dns verfication code each time


I'm getting some strange behavior on an AWS EC2 instance where if I run this command

sudo certbot certonly -v --manual --preferred-challenges dns -d www.somedomain.co.uk,somedomain.co.uk

Now if I run this twice on any other machine I get the same DNS verification codes in between runs, this is handy because it gives time to update the DNS whenever and then rerun the command to verify it.

On this particular instance, it gives a new key on every run, normally I'd just trash the instance and get a new one but this is a configuration we have on several load balancers, and would be rather a lot of headache to do so.

Any ideas anyone, please?



1 Like

You would ideally discard manual DNS as your validation method as it's at best a temporary method for testing. That's not a criticism of your approach, that just how it is. Can you elaborate on why you are not using DNS automation for the challenge?

The new token is the expected behavior as far as I know (previously completed validations are cached but I wasn't aware certbot did order re-use between runs). To my knowledge, with Certbot manual dns you're not supposed to continue until you've completed the DNS update and you're ready for certbot to check it.


That sounds unlikely.
The expected behavior is to receive a new code each time you run that command.


It's a rather long story, we're issuing these certificates for other people's domains so that we can add web infrastructure.

Flow is:

Customer Signs up for a product.
Customer adds CNAME redirect for _acme-challenge to point at _acme-challenge.theirdomain.OURDOMAIN.co.uk
Heres the problem.

Our DNS is on route53 BUT the record name for acme challenge is different to the RFC that certbot expects.

So then we need a way of running certbot , getting the keys, inserting them in the right record and then telling it to validate.

Re the validation keys, if you rerun the command within a certain amount of time they do repeat because it's not the local machine that has it, it's the letsencrypt server, so same account should give the same key back. Just for some reason on this machine it's not!

I don't understand this part. What's different exactly? If the DNS points to your nameserver, everything should work without anything fancy. Just use the certbot-dns-route53 plugin?

1 Like

Hey Osiris, because the plugin creates challenges that are _acme-challenge.ourdomain.co.uk rather than following the naming schema created by the customers CNAME record.

We could have everyone validate on a single record but if two customers subscribed at the same time they'd overwrite each others.

I suppose we could setup an automation queue to solve that though/

@Osiris Actually that's not a bad shout CNAME's can all point at _acme-challenge.ourdomain since we only issue/renew one at a time and then using the plugin we can get full automation without the issue of having to mess around with trying to get a repeated key.

You could consider running your own acme-dns server, then register and point customer domains at that. GitHub - joohoi/acme-dns-certbot-joohoi: Certbot client hook for acme-dns

Alternatively, you can also do _acme-challenge.whatever.co.uk CNAME to _acme-challenge.whatever.co.uk.auth.yourdomain.com but I'm not sure if the certbot route53 provider supports this domain/zone substitution. Some other clients do.

1 Like

Ah, I see, and that of course doesn't get recognised by your own route53s nameserver.

I think this issue is one of the (many) issues opened at the Certbot Github repo, but I wouldn't bet on getting this fixed anytime soon.

I also think it might be a good idea to setup acme-dns. Not only to fix this, but also for security reasons. I'm not sure how well Route53s access tokens can be secured.


I think they're pretty good for that, you can reduce their scope quite well: amazon web services - AWS Policy: Allow update specific record in route53 hosted zone - Stack Overflow


acme.sh have dns-alias mode . I think thats what you want


Ooo acme.sh looks very interesting thanks for that.


Not necessarily. I think the OP's application logic is making use of a design implementation detail...

This is the implementation detail: If you have an open order, and request the same exact set of domains from the same account, LetsEncrypt may simply return the first order instead of creating a second order. As the OP is using manual mode, unless the authorizations have an authorization triggered, LetsEncrypt should return the same order to the same account.

I'm not sure exactly what happens to the other authorizations in the order once an authorization is triggered -- i.e. if the pending authz are recycled into the next order or not.

The implementation detail of recycling the identical orders is a spec-compliant decision by LetsEncrypt. It's not defined in the spec and other CAs may handle it differently.

Anyways: Creating an Order, iterating over the challenges for setup, and not triggering the challenges should result in getting the same exact order, authz and challenges on a second identical order from LetsEncrypt.

  • Just noting all this because I am pretty sure this is what is happening. The advice to use acme-dns and other methods is spot-on IMHO.

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