# Guidance on offering custom domain names to clients **URL:** \ **Category:** Help\ **Created:** [March 29, 2024, 11:11am UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616 "2024-03-29T11:11:01Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![franck102](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/franck102/32/78674_2.png) [@franck102](https://community.letsencrypt.org/u/franck102)\ **Post date:** [March 29, 2024, 11:11am UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/1 "2024-03-29T11:11:01Z")
Hi all, 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](http://acme.com) is a client they would add a CNAME record to their zone to point [bookings.acme.com](http://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 ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [March 29, 2024, 11:27am UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/2 "2024-03-29T11:27:15Z")
Welcome to the Let's Encrypt Community! ๐Ÿ™‚ If a client CNAMEs `booking.example.com` to your (sub)domain name, you could satisfy either an [HTTP-01](https://letsencrypt.org/docs/challenge-types/#http-01-challenge) or [DNS-01](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) challenge from your (sub)domain name so long as your client does not have a [CAA record](https://en.m.wikipedia.org/wiki/DNS_Certification_Authority_Authorization) 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. ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [March 29, 2024, 11:34am UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/3 "2024-03-29T11:34:25Z")
If you use the DNS Challenge you can run that on any machine for any domain. You just need IAM authority to update Route53. You will get cert files from that request and you will need to write a script to update ACM. What kind of operating system will you run Certbot on? Here are Certbot docs for Route53 plugin. Other ACME Clients also support Route53 DNS Challenges [https://certbot-dns-route53.readthedocs.io/en/stable/](https://certbot-dns-route53.readthedocs.io/en/stable/) And info on the DNS Challenge itself > **[Challenge Types - Let's Encrypt](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge)** > > When you get a certificate from Letโ€™s Encrypt, our servers validate that you control the domain names in that certificate using โ€œchallenges,โ€ as defined by the ACME standard. Most of the time, this validation is handled automatically by your ACME... ---
**Author:** ![franck102](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/franck102/32/78674_2.png) [@franck102](https://community.letsencrypt.org/u/franck102)\ **Post date:** [March 29, 2024, 11:35am UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/4 "2024-03-29T11:35:16Z")
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! ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [March 29, 2024, 11:37am UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/5 "2024-03-29T11:37:36Z")
> [@franck102](#): > > CloudFront on AWS > [@franck102](#): > > use the CloudFlare DNS plugin Those are two different systems. I thought you were using Route53 for DNS and CloudFront for your CDN. ---
**Author:** ![franck102](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/franck102/32/78674_2.png) [@franck102](https://community.letsencrypt.org/u/franck102)\ **Post date:** [March 29, 2024, 11:38am UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/6 "2024-03-29T11:38:27Z")
Hi @MikeMcQ , 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. Franck ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [March 29, 2024, 11:40am UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/7 "2024-03-29T11:40:38Z")
> [@franck102](#): > > use the CloudFlare DNS 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 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. > [@franck102](#): > > 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? The TXT record would be created in your DNS, not theirs, and would need to be updated for every validation for issuance. ---
**Author:** ![franck102](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/franck102/32/78674_2.png) [@franck102](https://community.letsencrypt.org/u/franck102)\ **Post date:** [March 29, 2024, 11:41am UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/8 "2024-03-29T11:41:04Z")
Oops sorry, I meant the certbot Cloudflare plugin: [Docker](https://hub.docker.com/r/certbot/dns-cloudflare) - sorry for the typo. I am using CloudFront as our CDN, but all I need is to upload the generated certificates to ACM - I know how to take things from there. Franck ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [March 29, 2024, 11:46am UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/9 "2024-03-29T11:46:20Z")
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. ---
**Author:** ![franck102](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/franck102/32/78674_2.png) [@franck102](https://community.letsencrypt.org/u/franck102)\ **Post date:** [March 29, 2024, 11:46am UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/10 "2024-03-29T11:46:42Z")
Hmmm, I may be fundamentally misunderstanding how certificates work then? - we host our site at [great-bookings.com](http://great-bookings.com) - [acme.com](http://acme.com) subscribe to our service, and they agree that [https://booking.acme.com](https://booking.acme.com) should be served by us; so they create a CNAME [booking.acme.com](http://booking.acme.com) -\> [proxy.great-bookings.com](http://proxy.great-bookings.com) Now when a request for [https://booking.acme.com](https://booking.acme.com) hits our [proxy.great-bookings.com](http://proxy.great-bookings.com) we need to provide a certificate that covers [booking.acme.com](http://booking.acme.com), don't we? And ot obtain such a certificate the dns-01 challenge will require a TXT record in the [acme.com](http://acme.com) zone? Am I missing something? ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [March 29, 2024, 11:50am UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/11 "2024-03-29T11:50:30Z")
๐Ÿ™‚ 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`. ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [March 29, 2024, 11:54am UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/12 "2024-03-29T11:54:08Z")
Please pay special heed to [my post above](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/9). ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [March 29, 2024, 11:59am UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/13 "2024-03-29T11:59:30Z")
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. ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [March 29, 2024, 12:15pm UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/14 "2024-03-29T12:15:57Z")
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. ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [March 29, 2024, 12:22pm UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/15 "2024-03-29T12:22:27Z")
It's fun working with a TPV (yourself) in this scenario again. This scenario was very common in my last job. ๐Ÿ™‚ ---
**Author:** ![franck102](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/franck102/32/78674_2.png) [@franck102](https://community.letsencrypt.org/u/franck102)\ **Post date:** [March 29, 2024, 12:24pm UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/16 "2024-03-29T12:24:25Z")
> [@griffin](#): > > 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. Wow, that's a crucial piece of information I wasn't aware of, thanks! I will also look into HTTP-01 challenges, this may indeed be easier. Franck ---
**Author:** ![franck102](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/franck102/32/78674_2.png) [@franck102](https://community.letsencrypt.org/u/franck102)\ **Post date:** [March 29, 2024, 12:27pm UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/17 "2024-03-29T12:27:05Z")
> [@griffin](#): > > ๐Ÿ™‚ > > 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`. Hmmm, I lost you on the way here, what domains would the certificate cover? I have a certificate that is valid for [proxy.great-bookings.com](http://proxy.great-bookings.com), but https requests to [https://bookings.example.com](https://bookings.example.com) (which is a regular CNAME to [proxy.great-bookings.com](http://proxy.great-bookings.com)) fail with an SSL exception. I can directly hit [https://proxy.great-bookings.com](https://proxy.great-bookings.com) so the certificate is valid. So I concluded that I need a certificate for [bookings.example.com](http://bookings.example.com), and I assume that the TXT challenge to obtain such a certificate would need to be in the [example.com](http://example.com) zone? ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [March 29, 2024, 12:27pm UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/18 "2024-03-29T12:27:13Z")
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. ๐Ÿ˜‰ ---
**Author:** ![franck102](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/franck102/32/78674_2.png) [@franck102](https://community.letsencrypt.org/u/franck102)\ **Post date:** [March 29, 2024, 12:27pm UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/19 "2024-03-29T12:27:59Z")
You have precisely identified my motivation for posting here ๐Ÿ™‚ Thanks for the great help so far! Franck ---
**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\ **Post date:** [March 29, 2024, 12:31pm UTC](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616/20 "2024-03-29T12:31:51Z")
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. [Next page](https://community.letsencrypt.org/t/guidance-on-offering-custom-domain-names-to-clients/215616.md?page=2)