I am hoping to get clarity on how the DNS-01 Challenge works when it comes to having multiple web servers with multiple subdomains all needing SSL.
I have a system design that has the following separate web servers:
- frontend server which is accessible to the public through port 80 and 443. The domain is example.com
- backend server which only allows traffic through port 80 and 443 from the frontend IP address. The domain is backend.example.com
- admin panel server which only allows traffic through port 80 and 443 to a company IP address. The domain is admin.example.com
I would like to use DNS-01 Challenge to allow wildcard example.com domain; however, I want to minimize the risk of storing the API login credentials DNS manager on a servers.
So is it possible to only install CertBot on my #2 backend server (storing the API credentials for wildcarding and renewing my domain) and have my #1 and #3 server use my SSL cert even though they don't have CertBot installed?
Or do I need to install CertBot on every server which using a domain that has an SSL from LetsEncrtpy, thus, storing the API login credentials on every server.
I also found this great article from eff.org on how to minimize risk with using DNS-01.
Does anyone know of a walkthrough guide on how to use/configure the Limited DNS Zone Access or Use a "Throwaway" Validation Domain methods using AWS Route 53?
Thanks for your help in advance for my newbie questions.
Hi @c.artema, and welcome to the LE community forum
Yes; You will need to somehow copy/share the files between #2 and #1 & #3.
Thanks for the quick reply @rg305.
Can you please explain a bit more in detail your comment - which files would I be copying over?
To use a certificate, you really only need two files:
Adding on to Rudy's comment ...
Certbot creates these 4 files. Recent versions of Apache and nginx would use privkey.pem and fullchain.pem. Other servers may use something else. What servers do you run?
I am using Linux 20 Ubuntu with Nginx.
- I can install CertBot on 1 server and get my files there.
- I would then copy the fullchain.pem and the privakey.pem files to my other servers which would allow SSL to work on those domains.
Do you know where I would need to store those files for Nginx to pick them up and use them?
nginx would have to be "instructed" to use them.
There is no automatic "pickup cert files" location/procedure.
Meaning: You would have to modify the
nginx configuration to use the cert files.
[located anywhere you feel comfortable placing them]
And you would have to schedule the "synchronization" when the cert files are renewed.
And then also reload/restart the
nginx systems to let them all use the newest cert files.
I don't know of a walkthrough, but I may be able to give you a couple pointers (though I've not done this myself, I do use Route 53 for my DNS). Route 53 doesn't offer a "Limited DNS Zone Access" concept; a credential/role for AWS can just have
ChangeResourceRecordSets permissions or not have them, for an entire zone. So I think you want to use a separate validation domain zone.
If you just have one domain name, this isn't that bad, though because it's a new domain you have to pay AWS an extra $0.50 a month for it. Just create a new zone for
_acme-challenge.example.com, and put the NS records (that it normally instructs you to give to your "registrar") for them in your main zone, to delegate the subdomain zone.
If you have multiple domain names, you can do it the same way but it gets a little unwieldy (and possibly expensive). For that, if you want to stick with Route 53 you probably want to have a separate zone for all the domain challenges, and have a CNAME for
_acme-challenge from each of your domain names to that separate zone. But certbot doesn't support this case of authenticating one domain name by putting the record in a different domain name. Other clients do, like acme.sh has a "DNS Alias Mode" for this situation.
Another option that you may want to consider is using something like acme-dns for handling the challenge, so that rather than updating records dynamically in Route 53, you just have a CNAME to a different server that's running the acme-dns system, and have certbot update the records there. That's also a way to help limit your API credentials to just ones on the acme-dns system, rather than all of your DNS server.
While the above answers are completely correct, that you can request a wildcard certificate on one server and securely just copy them over to your other servers, another approach you may want to consider (assuming that you have the DNS API permissions restricted the way you want) is just having each server running its own certbot and requesting its own certificate for just its own name, rather than a wildcard. This would help limit impact so that one server wouldn't be able to emulate a different server, and each server would maintain its own certificate and renewals rather than you needing to worry about copying the keys and certificates around. It might not be better for your scenario, but it's an option you may want to evaluate.
Very few DNS providers offer granularity on their API login credentials that can actually minimize your security. While, as @petercooperjr mentioned, Amazon does offer some abilities for an added cost - the permissions system on AWS can be a bit unwieldy and is easy to mess up.
acme-dns, suggested by @petercooperjr and mentioned in that eff article, is the best option for automating DNS-01 challenges in any situation, and the docs should really reflect that. You can even use certbot's pre/post hooks to enable/disable the service and iptables routing as needed.
The only other option that is relatively secure is to run certbot on a local machine manually, and then deploy the certificates to your systems. There is no need for certbot to be on the target server when the DNS-01 challenge is used, and many advanced automation/deployment systems for clustered systems use this concept to centrally obtain and distribute certificates.