SSL for Customer Custom Domains: Issuing Certificates for Domains You Don't Own

How does a platform get a certificate for a customer's domain?

By proving present control, not ownership. A certificate authority never consults a registrar to ask whose name is on customer.com; it asks whoever is requesting the certificate to demonstrate that they can change something only a controller of that name could change. When your customer creates the record you asked for, they hand you exactly that ability, for exactly that name, for as long as the record stays there. The certificate then issues to you, carrying their hostname.

That distinction is the whole security model of custom domains, and it is worth stating plainly to anyone on your team who finds the arrangement uncomfortable. Nothing is being borrowed or spoofed. The customer is granting a capability, in public, in their own zone, and they can withdraw it in thirty seconds by deleting one record. The uncomfortable version would be a system where they could not.

What follows from that is the shape of every design decision below. Your platform is not really managing certificates; it is managing a large number of small, revocable grants of cooperation from people who do not work for you, most of whom will never think about the grant again after their first week.

Traffic and proof are two separate delegations

A custom domain needs two records doing two unrelated jobs. One routes requests: app.customer.com as a CNAME to something like tenants.yourplatform.net, which is what decides where a browser lands. The other proves control: _acme-challenge.app.customer.com as a CNAME into a validation zone you operate, which is what decides whether a certificate authority will issue. Onboarding flows that present this as one step called “point your domain at us” are the reason the two ever drift apart.

They drift in two directions, and each has its own signature. A tenant with traffic but no proof delegation looks perfectly healthy for months, because the certificate you issued during onboarding is still valid; it breaks on the day the renewal that was supposed to be invisible fails. A tenant with proof but no traffic gets certificates renewed on schedule for a hostname nobody can reach, which costs nothing except a slot in whatever rate limit you are working against.

Delegating the proof rather than collecting a fresh token each time is the part worth insisting on. The technique is the same one operators use for their own zones — a CNAME into a zone containing nothing but challenge records, so the credentials your issuance service holds cannot touch anything that matters. The mechanics, including the security argument for why a delegated zone beats handing an ACME client full DNS credentials, are covered in the guide to ACME challenge types. What changes in the multi-tenant case is only whose zone the CNAME starts in.

Which validation route works for a tenant domain?

Three routes work, and the choice is decided by what the customer will actually do rather than by which is technically nicer. HTTP-01 needs nothing beyond the traffic record they already created, which makes it the right default for self-serve signup. Delegated DNS validation needs one extra record but keeps working before cutover, covers wildcards, and does not ask the customer again at renewal. When a customer will do neither, they buy their own certificate and you install it.

HTTP-01's weakness is that it depends on you being the thing that answers the request, which stops being true the moment a customer puts a CDN, a WAF or a corporate proxy in front of their hostname. That change is invisible to you and entirely reasonable from their side, and the first symptom is a renewal failure some weeks later. Platforms that start on HTTP-01 and stay there tend to discover this once per large customer.

There is a real constraint on the DNS route that catches teams late. Only one CNAME can exist at a given name, so _acme-challenge.app.customer.com can be delegated to exactly one solver. A customer who already delegates that name to another vendor cannot simply add a second record. The CA/Browser Forum adopted a fix for precisely this in ballot SC-084 (January 2025), which added validation method 3.2.2.4.21, “DNS Labeled with Account ID — ACME”. It corresponds to the dns-account-01 challenge, which prepends a label derived from the requesting ACME account to the validation name, so two providers validating the same hostname no longer contend for the same record. Support is still spreading across certificate authorities and clients, so treat it as the answer to plan toward rather than one to assume today.

Why apex domains break the pattern (and why validation doesn't)

A zone apex cannot carry a CNAME. DNS does not permit a CNAME to coexist with other records at the same name, and an apex must hold its SOA and NS records, so customer.com cannot be CNAMEd to your platform while www.customer.com can. This is a routing problem with two ordinary answers: a provider-specific ALIAS or ANAME record that behaves like a CNAME but publishes A records, or plain A records pointing at addresses you own.

The part that gets conflated, and the reason this section exists, is that the apex restriction says nothing about validation. _acme-challenge.customer.com is a name below the apex, not the apex itself, so it can carry a CNAME even on a zone whose root cannot. A customer who tells you their root domain “can't use CNAMEs” is describing a traffic constraint; delegated validation for that same root domain remains available to them.

Where the apex genuinely costs you something is in the A-record fallback, because it pins your IP addresses inside a zone you do not control. Renumbering then becomes a coordination exercise across every customer who took that route, at whatever pace their change processes allow. Platforms that expect to move addresses usually steer apex customers toward an ALIAS-capable DNS provider during onboarding rather than negotiating it later under time pressure.

What a customer's CAA record does to your issuance

A CAA record on the customer's domain can block your certificate even when domain control validation succeeds. CAA lets a domain holder name which certificate authorities may issue for their names, and a CA that finds itself excluded is obliged to refuse. Nothing about your delegation is wrong in that case, and no retry will help — the answer lives in the customer's zone.

This lands hardest on exactly the customers you least want it to. A small tenant usually has no CAA record at all, which means no restriction. A large, security-conscious enterprise is precisely the one that published a CAA set years ago naming the CA it buys from, and that record is now quietly refusing the certificate your platform needs. Reading CAA for the hostname during onboarding, before the first issuance attempt, converts a confusing failure into a specific request you can put in front of them.

The request itself can be narrower than “please allow this CA”. RFC 8657 adds two parameters to CAA: accounturi, which restricts issuance to one named ACME account, and validationmethods, which restricts it to specific validation methods. A customer can therefore authorise your platform's ACME account to obtain certificates for their name through delegated DNS validation and nothing else, which is a materially easier thing for a security team to approve than a blanket grant. If they want the background first, our guide to CAA records covers the syntax and the failure modes.

Why the 2026 reuse cut decides the architecture

Two clocks are shrinking, and for a multi-tenant platform the second one matters more. Under CA/Browser Forum ballot SC-081v3, maximum certificate validity fell from 398 days to 200 on 15 March 2026, and falls to 100 in March 2027 and 47 in March 2029. The domain validation reuse period follows the same first two steps — 200, then 100 — and then drops much further, to 10 days, in March 2029.

The reuse number is the one that touches your customers, because it measures how long a single act of their cooperation keeps counting. At 200 days, a token pasted into a form during onboarding could plausibly carry a tenant through a renewal or two before anyone noticed it had gone stale. At 10 days, every tenant name needs proof that answers roughly three times a month, indefinitely, without a human being asked. Any design that routes through customer attention stops working somewhere between those two numbers.

Read that as a deadline rather than a warning. A standing delegation — one CNAME the customer creates once and leaves alone — satisfies a validation every ten days as easily as one every two hundred, because nobody has to do anything for it to keep answering. A workflow built around emailing customers a fresh TXT value degrades gracefully into a support queue and then into churn. The wider set of changes arriving on the same schedule is covered in the 2026 domain validation changes, and multi-perspective validation adds a second reason to prefer DNS delegation over anything that depends on a single network path.

Free DV or a commercial certificate for tenant domains?

For the padlock, free DV automation is the correct default and the honest recommendation. Browsers do not distinguish between a free domain-validated certificate and a paid one for trust purposes, the cryptography is identical, and issuing thousands of tenant certificates through ACME costs nothing per name. A platform that bills per custom domain is charging for the automation, not for the certificate.

Commercial certificates earn their place in the exceptions, and the exceptions are specific rather than general. One is the tenant whose procurement or security review requires the certificate to name a legal entity, which only organization validation provides — that request usually arrives from a regulated buyer who reads subject fields, and it is answered with an organization-validated certificate ordered for that one customer rather than a change to your pipeline. Another is a warranty or a support relationship the tenant's contract depends on. A third is an environment where the automation itself is the risk: an air-gapped deployment, or a customer whose change process cannot accommodate a certificate that rotates every few weeks.

One structural point is worth being clear about, because it surprises people who assume OV can be bulk-issued the way DV is. Organization validation vets the organization named in the certificate, so a platform cannot mass-produce OV certificates on behalf of its customers the way it mass-produces DV. Those stay individual orders against the tenant's own organization details. Where several of a tenant's hostnames belong on one certificate, a multi-domain certificate covers them in a single order rather than several.

The failure modes that only appear at scale

Custom domains work fine for the first fifty tenants and start teaching lessons somewhere in the hundreds. The failures are rarely cryptographic; they are almost always a customer changing something in their own zone, a limit you did not know you were near, or a certificate that outlived the arrangement that justified it.

The offboarding row is the one worth a policy rather than a fix. Continuing to hold and renew a valid certificate for a former customer's hostname is not a security breach, but it is a capability you no longer have any business holding, and it is exactly the sort of thing that reads badly in a security questionnaire. Stop renewal at account closure and let the last certificate expire.

The packing row deserves the same treatment for a different reason. Putting unrelated customers' hostnames into one certificate means every one of them can read the others' names out of the certificate they are served, which is a disclosure your customers did not agree to and would notice if they looked. Shared certificates belong to names you control; customer-owned names get their own.

FAQ