Custom Domains: Issuing Thousands of Certificates Without Touching One
What actually happens when a customer points their domain at your platform, and why the certificate usually fails at the step nobody planned for.
"Connect your own domain" is one line on a pricing page and considerably more behind it: proving ownership, issuing and renewing a certificate, routing the request to the right tenant, and handling the customer who edited their DNS and then forgot.
Ownership comes first
Before issuing any certificate you have to establish that the customer controls the domain. Two approaches work: a TXT record with a value you generate, or a CNAME pointing at your zone. The second is better because it does two jobs at once — it proves control and it routes traffic.
Why CNAME rather than A
- An A record freezes an IP address into your customer's settings, and you can never move your infrastructure afterwards.
- A CNAME keeps control on your side: you change the target without anyone touching their DNS.
- The exception is the apex: most DNS providers forbid CNAME there, so you need ALIAS, ANAME, or a policy of using www.
Automate renewal or you will forget it
One manual certificate is trivial. A thousand certificates expiring at different times is an outage waiting for a date. Use ACME with a DNS-01 or HTTP-01 challenge, issue on activation, and renew at a third of the lifetime remaining rather than on the last day. Track near-expiry certificates as an operational metric, not as something you remember.
A renewal path that works 99% of the time means a broken customer site roughly every week once you have a thousand domains.
Routing the request to the right tenant
Once the request arrives you have to map hostname to tenant. Build a domain-to-tenant lookup and keep it in a cache close to the edge, because it is consulted on every single request. Remember the hostname may be the custom domain or the default subdomain — both must resolve to the same place.
The failures that repeat
- Not handling a CAA record that excludes your certificate authority — issuance fails with an opaque error.
- Assuming the customer removed their old provider's records, so traffic splits between two destinations.
- Activating before DNS has propagated, so the customer sees an error and concludes the feature is broken.
- Forgetting to revoke the certificate and clean up routing when a domain is removed.
The protocol underneath all of this is ACME, RFC 8555, and Let's Encrypt's guide to challenge types is the clearest practical explanation of when DNS-01 beats HTTP-01. The CAA record that silently blocks issuance is specified in RFC 8659.
If you are building a platform whose customers need this, budget the operating cost rather than only the build: talk to us about the design before you discover what renewal costs across a thousand domains.
FAQ
One certificate per domain, or one shared certificate?
Per domain is simpler to manage and lower risk; a combined certificate means one problem takes down many customers at once.
What about customer subdomains?
Cover those with a wildcard on your own zone and keep customer-owned domains separate.
How should cancellation be handled?
Stop routing first with a short grace period, then revoke the certificate and remove the record, so no hostname keeps pointing at your infrastructure.