How SSL Provisioning Works for Custom Domains
Custom-domain SSL works in four moves: the customer points a CNAME at your app, an ACME client proves control of that hostname to a certificate authority (usually with a DNS-01 or HTTP-01 challenge), the CA issues a certificate, and your edge serves it using SNI. Renewal repeats the cycle every 60 to 90 days, forever, for every domain.
Domainee is a custom domains API for SaaS with a native MCP server, 50 domains and 100 GB free. I build it, so I spend a lot of time inside this pipeline. This post is the mental model I wish I'd had the first time a customer said "my domain works but it says Not Secure." None of it is Domainee-specific until the last section: it is how automatic TLS works for any product that lets customers bring their own domain.
The four-step pipeline
Every custom-domain certificate, on every provider, goes through the same stages:
- Point. The customer adds a DNS record (a CNAME, or an A record for an apex) that aims their hostname at your infrastructure.
- Prove. Before any certificate authority will sign a certificate for
shop.acme.com, someone has to prove they control that name. That proof is an ACME challenge. - Issue. The CA, almost always Let's Encrypt or a similar automated authority, signs a certificate valid for 90 days.
- Serve. Your edge presents the right certificate on the TLS handshake, picking it by hostname with SNI.
The interesting decisions all live in steps 2 and 4. Get those wrong and you get the two classic failure modes: certificates that never issue, and certificates that issue but never get served.
Proving control: DNS-01 vs HTTP-01
ACME defines a few challenge types. Two matter for custom domains, and picking between them shapes your whole onboarding flow.
HTTP-01 asks you to serve a specific token at http://the-hostname/.well-known/acme-challenge/<token> over port 80. The CA fetches it. If it matches, control is proven. Simple, but it only works once the hostname already resolves to you and port 80 is reachable.
DNS-01 asks you to publish a TXT record at _acme-challenge.the-hostname. The CA queries DNS instead of making an HTTP request. It works before the host is reachable and it is the only challenge that can issue a wildcard, but it needs programmatic access to the DNS zone.
| HTTP-01 | DNS-01 | |
|---|---|---|
| Proof mechanism | Token file on port 80 | TXT record at _acme-challenge |
| Works before host resolves to you | No | Yes |
| Can issue wildcards | No | Yes |
| Needs DNS API access | No | Yes |
| Common failure | Port 80 blocked or redirected | TXT propagation lag |
For bring-your-own-domain SaaS, the honest answer is that you often want both. HTTP-01 is the path of least resistance once the customer's CNAME is live, which is why most custom-domain providers lead with it. DNS-01 is what you reach for when you are issuing a wildcard for your own subdomains, or when a customer's setup can't expose port 80. There is also TLS-ALPN-01, which runs the proof over port 443, but it is a niche tool for edge proxies rather than something you expose to customers.
One rule saves more support tickets than any other: verify the CNAME actually resolves before you trigger the challenge. Let's Encrypt caps failed validations at 5 per account, per hostname, per hour, so a retry loop against an unready domain will lock you out fast. A quick DNS propagation check gates the request cleanly.
Which certificate: wildcard vs SAN vs single-name
Once control is proven, there is a second decision: what shape of certificate to ask for.
A single-name certificate covers exactly one hostname. A wildcard covers every direct subdomain of one parent (*.example.com). A SAN, or multi-domain certificate, lists several unrelated names on one certificate.
| Single-name | Wildcard | SAN / multi-domain | |
|---|---|---|---|
| Covers | One exact host | All subdomains of one parent | Several listed hosts |
| Issued via | HTTP-01 or DNS-01 | DNS-01 only | HTTP-01 or DNS-01 |
| Fits | One customer domain | Your own *.app.example.com tenants | A batch of known domains |
| Gotcha | One cert per host to renew | Does not cover the apex | Reissue to add or remove a name |
For customer domains you almost always want a single-name certificate per hostname. Customers bring unrelated apex domains, and a wildcard can't span two different parents. Wildcards earn their keep for your own subdomain-per-tenant pattern (acme.yourapp.com, globex.yourapp.com), where one certificate covers every tenant. Note the trap in the table: *.example.com covers app.example.com but not example.com itself, so an apex needs its own name on the certificate.
Serving it: SNI, one IP, many certificates
Issuing the certificate is only half the job. On every HTTPS request, your server has to present the correct certificate before it knows anything about the request except the target hostname, which the client sends in the clear in the TLS ClientHello. That field is SNI, the Server Name Indication extension defined in RFC 6066.
SNI is the reason a single IP can host certificates for thousands of customer domains. Without it, each hostname would need its own IP address, and the economics of custom-domain hosting would collapse. When you see a "certificate name mismatch" or a customer's browser showing the wrong site's certificate, SNI selection is usually where it broke: the edge received the handshake but had no certificate bound to that hostname yet, so it fell back to a default. The SSL certificate checker shows exactly which certificate a host is serving and for which names, which is the fastest way to tell "not issued" apart from "issued but not bound."
Renewal is the real work
A certificate that issues once is easy. The system that keeps thousands of them valid is the actual product.
Let's Encrypt certificates are valid for 90 days, and the standard practice is to renew about 30 days before expiry so you have a wide window to retry failures. Renewal is not a lighter operation than issuance: it re-runs the full challenge, so every reason a first issue can fail (a customer moved their DNS, port 80 got firewalled, the CNAME changed) can also fail a renewal, silently, weeks after the domain last worked. That is why monitoring customer certificate expiry at scale matters more than the initial handshake, and why certificate renewal deserves its own alerting rather than being treated as a background detail.
The other ceiling to design around is rate limits. Let's Encrypt allows 50 certificates per registered domain per week and 5 duplicate certificates per week. You will not hit those by hand, but a bug that reissues on every deploy, or a fleet of subdomains under one registered domain, can. Batch renewals, cache aggressively, and never reissue a certificate that is still valid.
What Domainee automates
Everything above is the work you would own if you built this yourself: an ACME client, DNS or port-80 plumbing for challenges, per-hostname certificate storage, SNI-aware edge routing, a renewal scheduler, and expiry alerting. That is a quarter of engineering before your product is any different from the day you started.
Domainee runs the whole pipeline behind one API call. You send a hostname, you get back a CNAME target, and Domainee handles the challenge, issuance, SNI binding, and renewal. DNS and SSL probes are exposed as endpoints (and as MCP tools) so an agent can debug a stuck domain without a human. The step-by-step version, including the Cloudflare comparison, is in the custom domains SSL setup guide; the pricing-versus-build math against every provider is in the custom domain API comparison; and the SSL for custom domains overview is the short pitch.
You can wire it up on the free tier (50 domains, 100 GB) without a card.
FAQ
How does SSL work for custom domains? A certificate authority issues a TLS certificate for the customer's hostname after an ACME client proves you control that name (via a DNS-01 or HTTP-01 challenge), and your edge serves the certificate on each request by selecting it with SNI. The certificate is renewed automatically every 60 to 90 days.
Do I need a separate certificate for every customer domain? Usually yes. Customer domains are unrelated apex names, and a single certificate can only span multiple names via a wildcard (same parent) or a SAN list (names you enumerate up front). The common pattern is one single-name certificate per customer hostname, issued and renewed automatically.
Why does DNS-01 support wildcards when HTTP-01 does not?
A wildcard like *.example.com has no single hostname to serve a token from, so HTTP-01 cannot validate it. DNS-01 proves control of the whole zone through a TXT record at _acme-challenge.example.com, which is enough for the CA to sign a wildcard.
What is SNI and why does custom-domain hosting need it? SNI (Server Name Indication, RFC 6066) is a TLS extension that carries the target hostname in the ClientHello, before the certificate is chosen. It lets one IP present the right certificate for thousands of hostnames, which is what makes custom-domain hosting economical.
How often do custom-domain certificates renew? Let's Encrypt certificates last 90 days and are typically renewed around 30 days before expiry. Renewal re-runs the full ACME challenge, so it can fail whenever the customer's DNS or reachability changes, which is why expiry monitoring matters as much as first issuance.