Guide

How to automate TLS for customer domains

To serve HTTPS on many customer-owned domains, you automate certificate issuance over ACME and automate renewal, ideally issuing certificates on demand the first time a domain is requested. That way every customer domain gets a valid certificate without you touching a certificate authority or babysitting a cron job. Custom Domain issues and renews these certificates at the edge and keeps them in step with the DNS records your customers add.

What makes multi-domain TLS hard

A single certificate for your own marketing site is easy. The hard part starts when hundreds or thousands of your end customers each bring their own domain, such as app.acme.com or dashboard.globex.io, and each one needs its own valid, trusted certificate at your edge.

Several problems compound at once. First, per-domain certificates: public certificate authorities will only sign a name once you prove control of it, so you cannot pre-issue a certificate for a domain a customer has not verified yet. Second, issuance rate limits: ACME certificate authorities cap how many certificates you can request per registered domain and per account over a rolling window, so a naive loop that requests everything at once will get throttled. Third, SNI at the edge: your terminating server has to select the right certificate based on the hostname in the TLS handshake, which means fast lookups across a large and changing set of names. Fourth, renewal: certificates are short lived, often around ninety days, so ten thousand domains means thousands of renewals every month that all have to succeed unattended. Fifth, fail-closed behavior: if issuance or renewal quietly fails, the customer sees a browser security warning instead of your product, so the system has to retry, alert, and degrade safely rather than serve a broken handshake.

See multi-tenant TLS for how these pieces fit together across many tenants.

On-demand TLS: issue on first request

The cleanest way to handle a large, shifting set of domains is on-demand TLS. Instead of trying to pre-provision certificates for every domain, the edge issues a certificate the first time it sees a live TLS handshake for a hostname it recognizes as an approved customer domain. The first connection may take a moment longer while the certificate is obtained, and every connection after that is served from cache.

On-demand issuance solves the timing problem cleanly. You do not need to know in advance exactly when a customer will point their domain at you. When their DNS starts resolving to your edge and the domain is on the approved list, the certificate appears. It also spreads issuance out naturally, since certificates are requested as traffic arrives rather than in one large batch, which is friendlier to rate limits. The important guardrail is an allowlist check: the edge must only attempt issuance for domains already verified as belonging to a real customer, otherwise an attacker could point arbitrary hostnames at you and burn your issuance quota. See on-demand TLS for a fuller definition.

Automating ACME

Under the hood, automated issuance almost always speaks ACME, the standard protocol for requesting and validating certificates without a human in the loop. Let's Encrypt is a widely used ACME certificate authority and a fine neutral example, and the same flow works with other ACME providers.

The flow is straightforward in principle. Your client creates an account key with the certificate authority, then asks for a certificate covering a specific hostname. The authority returns a challenge that proves you control that name. There are two common challenge types. An HTTP challenge asks you to serve a specific token at a well-known path over port 80 for the domain, which suits on-demand issuance at an edge that already receives the traffic. A DNS challenge asks you to publish a specific TXT record under the domain, which is what you need for wildcard certificates and works even before traffic is routed to you. Once the challenge is satisfied, the authority validates it, and your client finalizes the order and downloads the signed certificate.

Doing this reliably at scale means solving the operational details around the protocol: storing account and certificate keys securely, backing off and retrying when you hit rate limits, distributing issued certificates to every edge node that terminates TLS, and reacting when a customer changes their DNS. Custom Domain runs this ACME flow for you and issues certificates at the edge as customer domains come online. For the exact challenge types, validation paths, and how issuance is triggered, see the documentation.

Renewal and revocation

Issuance is only half the job. Because certificates are short lived, renewal has to be as automatic as the first issuance, and it has to run continuously in the background. A common pattern is to renew a certificate well before it expires, for example when it is roughly two thirds through its lifetime, so there is a wide margin to retry if a renewal fails. Renewal reuses the same ACME flow, revalidating control of the domain each time.

This is where staying in step with DNS matters. If a customer moves their domain away, changes the record that points at your edge, or lets the domain lapse, a renewal that assumes the old state will fail. A robust system watches the domain state and stops attempting renewals for domains no longer pointed at you, while alerting on domains that should still be live but suddenly cannot revalidate. Custom Domain keeps certificates aligned with the DNS records your customers add and renews them before expiry, so a working domain keeps working without anyone remembering to act.

Revocation is the rarer path. If a private key is exposed, or a customer offboards and you want to invalidate an existing certificate, you revoke it with the issuing authority and stop serving it. In practice, letting a certificate expire naturally and removing the domain from your allowlist covers most offboarding cases, and explicit revocation is reserved for key compromise.

Build vs buy

You can build all of this yourself. The pieces are well documented, ACME clients are mature, and for a handful of domains a script and a scheduled job are genuinely enough. The cost shows up as you grow: rate-limit accounting, secure key storage and rotation, certificate distribution across edge nodes, SNI selection at scale, renewal retries, DNS state tracking, and clear alerting when something fails closed. Each is manageable in isolation, and together they become a system your team owns and pages on.

Buying means issuance, renewal, SNI selection, and the coupling between DNS and certificates are handled for you, and your job shrinks to marking a domain as approved and pointing your customer at the right records. That is the trade Custom Domain is built for: it detects the customer DNS provider, writes the records, verifies ownership, and issues HTTPS at the edge, so your end users never open a DNS panel. For a wider view of the whole customer-domain problem, read custom domains for SaaS.

FAQ

Do I need a wildcard certificate for customer domains?

No. Customer domains are distinct registered names you do not own, so a wildcard on your own domain does not cover them. Each customer domain gets its own certificate, issued per hostname over ACME.

Will the first request to a new domain be slow?

With on-demand TLS the very first handshake for a brand new domain can take a moment while the certificate is issued, then it is cached and every later request is served at normal speed. You can also warm a certificate ahead of time once a domain is verified.

How do I avoid hitting ACME rate limits?

Issue certificates as domains come online rather than in one large batch, back off and retry on limit errors, and only attempt issuance for verified domains on your allowlist. On-demand issuance spreads requests out naturally, which helps.

What happens when a customer changes their DNS?

A system that tracks domain state stops renewing certificates for domains no longer pointed at your edge and flags domains that should be live but cannot revalidate. Custom Domain keeps certificates aligned with the DNS records your customers add.

Where are the exact issuance and renewal mechanics documented?

The exact challenge types, validation paths, and how issuance is triggered are in the documentation. This guide describes the standards-based process rather than product-specific API calls.