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.
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.
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?
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.
@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.
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.
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.
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.