I’m in the midst of designing the dns validation portion of my Let’s Encrypt deployment (previous threads I have indicated this is a large deployment across hundreds of systems). I’ve already researched several methods of validation as noted here. As I’m required to use AWS Route53, AWS still does not allow you to have an IAM policy that controls the type of DNS record (TXT); the only option I seem to have is to create a subdelegate zone, and point NS records towards the new zone, and then point the “_acme-challenge” validation subdomains to them using the CNAME records.
With that said, it seems I would have to do the following:
Let’s say I have an existing domain for .foo.com in Route53 (where this is the domain I will be using to generate x509 certificates for e.g. test.foo.com, test1.foo.com, and so on).
I believe I have to create a sub-delegate zone within this domain as my validation domain. Let’s call it “acme.foo.com”.
I then have to point the new sub-delegate zone (acme.foo.com) to foo.com with the ns records etc.
New “_acme-challenge” validation subdomains will use “acme.foo.com” sub-delegate zone, as such for a new certificate performing validation it will have foo_acme-challenge.acme.foo.com via CNAMES.
My questions are as follows:
Is this the correct setup?
Is this baked into the route53 plugin?
How can I force the route53 plugin to use the new sub-delegate zone so it’s not using the domain of the common name of the certificate?
From a first glance it's a correct setup. It sounds like what you're doing is reasonably sophisticated, and I can see several ways that it could be done so I don't know if there is a "the" correct setup. It also depends on why exactly using a IAM role with full access to the domain name isn't going to work for you. I certainly see how AWS offering a more locked-down IAM role would be better, but one approach that I might explore if I were doing something similar would be to see if I could have a single Lambda function with a role with full ChangeResourceRecordSets permissions. When a system requested a new certificate it would send a message to that Lambda (through API Gateway, SNS, SQS, or whatever) to have the Lambda function make the DNS update. That one place could ensure that only authorized TXT acme-challenge records are edited, and then it just becomes a matter of ensuring that those Lambda's permissions are locked down so nobody else could edit it to mess with other DNS records. But if you have an IT Security Department just saying "No, nothing is going to get ChangeResourceRecordSets permissions on our main domain" then something like that obviously wouldn't work for you and you'd need to do something more like what you're suggesting.
If you're going to go fully everything-in-AWS route you might even have the Lambda do the renewals itself, store the certificates in AWS Secrets Manager, and have the servers pull their certificates out of there. I did something similar as a little hobby project for my personal domain, though just using S3 (since it's cheaper) to store the keys. I'm not sure if that's really the way to do it for an enterprise-scale deployment, though.
I don't think it's something you can do through certbot out-of-the-box. You might need to write your own plugin or use one of the other many clients. Regardless you may end up needing to write some code of your own to make everything work the way you want, but it may just be that I'm a programmer so I'm used to putting together the building blocks that are out there a slightly different way since nothing is ever already quite the way I want it myself.