I am new to Let's Encrypt and struggling to figure out a strategy for the scenario we want to support: we offer a hosted booking service to multiple clients, and we would like to allow them to serve our site under their custom domain name.
So if for example acme.com is a client they would add a CNAME record to their zone to point bookings.acme.com to our domain, which is hosted on AWS Route53.
I have tried going through the certbot documentation but
a) most of it relates to pointing a web server at the certificate whereas I need to import certificate into AWS certificate manager; and
b) the docker certbot instructions specify starting the container "from the server that the domain you’re requesting a certificate for resolves to".
In my case I need to obtain and renew the certificate from our machines (either local our some AWS instance/task) for a domain that is completely unrelated.
Is certbot running in Docker on AWS the right direction to investigate; and if so can the instance run inside our domain to obtain certificates for an external subdomain?
Thanks!
My web server is (include version):
CloudFront on AWS
The operating system my web server runs on is (include version):
AWS
My hosting provider, if applicable, is:
AWS Route 53
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):
n/a
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
n/a
If a client CNAMEs booking.example.com to your (sub)domain name, you could satisfy either an HTTP-01 or DNS-01 challenge from your (sub)domain name so long as your client does not have a CAA record for their (sub)domain name that prevents certificate issuance. This is a basic delegation scenario. Keep in mind that to properly use the acquired certificate, your webserver configuration will need to be configured to serve requests made for the booking subdomain of your client's domain name.
Thanks Griffin, I know the DNS-01 challenge will work for the first client I have in mind, and I know how to server their subdomain from my servers.
Experimenting with certbot on Docker I seem to have a couple options:
use the certbot dns-cloudflare plugin: it seems I can then automate renewal, however I will need a different plugin & setup if the next client is not using Cloudflare; and I need the client to create a Cloudflare API key which they may be reluctant to do
use a dns-01 challenge: this should work across client providers, however is there a way to keep the same TXT challenge when renewing the certificate so that the client only needs to create the record once and for all?
Thanks for the pointers. I probably shouldn't have mentioned Route53 which we use but which has no bearing on my scenario, the clients could be using any provider, our first client is using Cloudflare.
Certbot will likely be running in a AWS Lambda, a scheduled ECS task or something similar in our infrastructure.
Whether the client is using Cloudflare would be irrelevant since their booking subdomain name would be delegated to your (sub)domain name at the DNS level, meaning that the HTTP request traffic wouldn't be funneled through their Cloudflare.
The TXT record would be created in your DNS, not theirs, and would need to be updated for every validation for issuance.
I should probably point out that there's a HUGE difference between a true CNAME delegation and a Cloudflare reverse-proxy (pseudo) CNAME. The former is a DNS delegation while the latter is a "hook" of sorts for directing HTTP traffic to a custom backend.
You're generally on track with one major exception:
If your client truly CNAMEs their booking subdomain name to proxy.great-bookings.com then the DNS-01 TXT record would be under _acme-challenge.proxy.great-bookings.com, not _acme-challenge.bookings.example.com.
Personally, I would highly recommend using HTTP-01 challenges if at all possible. They will save you a lot of headaches with DNS delegation conundrums. You know the HTTP traffic for booking.example.com will hit your webserver, so you can just serve the HTTP-01 challenge files from there. That way, your client can have whatever CDN situation they want and control their own traffic. In essence, you don't actually need a DNS delegation of booking.example.com to your (sub)domain name to pull off your scenario. You just need their HTTP traffic requests to hit your webserver, which can be accomplished via the client's reverse-proxy or even a simple A/AAAA record in the client's DNS if your (sub)domain name has a static IP address. The reverse-proxy route with client's CDN is cleaner and much more likely.
Sorry to deluge you with info in so many posts. I would be remiss if I didn't point out that how your client sends HTTP requests to your webserver is crucial here. If they are rewriting the HTTP request headers (very common in CDN reverse-proxy scenarios) to match your (sub)domain name then you would be serving a certificate covering your (sub)domain name, not theirs. This is best practice and highly recommended.
So I concluded that I need a certificate for bookings.example.com, and I assume that the TXT challenge to obtain such a certificate would need to be in the example.com zone?
With you being a TPV, I strongly recommend establishing your pattern/protocol for service to be as generically-attachable as possible to drastically reduce both your turnup time with new clients and the time you'll spend debugging with them and hoping they have the appropriate technical resources.
The key here is to distinguish DNS requests from HTTP requests. The TXT record request will go through DNS passing through client's zone to yours due to delegation. For HTTP requests (where certs are served), once a visitor has looked up the A/AAAA record to get to your webserver via the DNS delegation or reverse-proxy from client, the requests will be made to your webserver either under their subdomain name or yours. Knowing which is crucial. You could prepare for both scenarios, but that would be extra work.
