Glossary

Multi-tenant TLS

Multi-tenant TLS is the practice of issuing and serving valid HTTPS certificates for many customer-owned domains from a single platform. Each tenant brings its own domain, and the platform terminates TLS for all of them at one shared edge, presenting the correct certificate for whichever hostname the visitor requested.

In a multi-tenant product, hundreds or thousands of end customers each point a domain at your service. Every domain needs its own trusted certificate so browsers show the padlock and never warn the visitor. Doing this by hand does not scale, so multi-tenant TLS automates certificate issuance, storage, renewal, and selection, making a new customer domain a background operation rather than a support ticket.

Why is TLS harder for multi-tenant SaaS?

A single-domain app needs one certificate. A multi-tenant platform needs one certificate per customer domain, and those domains are not yours. You cannot pre-provision them, you do not control their DNS, and they arrive continuously as customers sign up. The hard parts are concrete. Certificate authorities enforce issuance rate limits, so a burst of new domains can hit a ceiling. Every certificate expires and must renew on schedule or the site breaks. The edge has to pick the right certificate for the right hostname on every connection. And when issuance fails, the platform has to fail closed rather than serve a broken or mismatched certificate.

Per-domain certificates versus wildcard certificates

A wildcard certificate covers many subdomains of one domain you control, for example every subdomain under your own platform domain. It is a good fit when your customers live on subdomains of your domain. It does not help when customers bring their own apex or root domains, because a wildcard for your domain cannot cover an unrelated customer domain, and you cannot obtain a wildcard for a domain you do not own without their DNS cooperation.

For customer-owned domains, the durable answer is a per-domain certificate: one certificate issued for each specific hostname a customer brings. Per-domain certificates scale to any number of tenants, keep each domain isolated, and match the reality that every customer domain is validated and renewed independently. The tradeoff is volume, because you are now running an issuance and renewal pipeline across your entire tenant base.

How does certificate issuance work at scale?

Each customer domain has to prove control before a certificate authority will sign a certificate for it. That proof is a validation challenge, typically satisfied by writing a DNS record or answering an HTTP request at the domain. Once ownership is verified, the certificate is issued, stored, and pushed to the edge that terminates TLS. At scale this loop runs constantly as tenants come and go, and it must respect the rate limits certificate authorities place on how many certificates can be requested in a window.

Those rate limits are why naive approaches stall. If you request certificates too aggressively, or retry failures in a tight loop, you can exhaust your allowance and block legitimate new domains. A working pipeline paces requests, batches where it can, caches successful issuances, and backs off cleanly on transient failures so a single bad domain does not starve everyone else.

What is SNI and why does it matter at the edge?

Server Name Indication, or SNI, is the part of the TLS handshake where the browser tells the server which hostname it wants before the certificate is chosen. This is what makes multi-tenant TLS possible on shared infrastructure: the edge reads the hostname from SNI and selects the matching certificate from the many it holds. Without SNI, one address could present only one certificate. With it, a single edge serves valid HTTPS for every tenant domain, choosing the right certificate per connection.

Renewal and failing closed

Certificates are short-lived, so renewal is not optional. Every tenant domain has to renew ahead of expiry, automatically, or a visitor hits a browser security warning the day it lapses. A multi-tenant platform tracks each certificate's expiry, renews well before the deadline, and retries safely if an attempt does not land.

Equally important is what happens when issuance or renewal genuinely cannot complete, for example because a customer changed their DNS and validation now fails. The safe behavior is to fail closed. The platform should never present an invalid, expired, or mismatched certificate, because that is worse than an honest error. Failing closed keeps every other tenant secure and surfaces the broken domain for follow-up.

How Custom Domain handles multi-tenant TLS

Custom Domain runs the entire pipeline for you. When one of your customers brings a domain, we detect their DNS provider, write the records needed to prove control, verify ownership, and issue a per-domain certificate for that exact hostname. The certificate is served from a shared edge that uses SNI to present the correct certificate on every connection, so you never provision one by hand or manage a wildcard workaround.

Renewal is automatic and continuous. We track expiry across every tenant domain and renew ahead of the deadline, pace issuance to stay within certificate authority rate limits, and fail closed when a domain cannot be validated so one broken domain never puts other tenants at risk. Adding a customer domain becomes a background step in your product rather than an operations project.

Frequently asked questions

What is multi-tenant TLS?

It is issuing and serving valid HTTPS certificates for many customer-owned domains from one platform, with the edge presenting the correct certificate for each hostname it receives.

Should I use a wildcard certificate or per-domain certificates?

Use a wildcard when customers live on subdomains of your own domain. Use per-domain certificates when customers bring their own domains, since a wildcard cannot cover domains you do not own.

How do issuance rate limits affect a multi-tenant platform?

Certificate authorities cap how many certificates you can request in a window. A multi-tenant platform must pace and batch requests so a burst of new domains does not exhaust the allowance and block legitimate customers.

What happens if a certificate fails to issue or renew?

The platform should fail closed. It never serves an invalid or mismatched certificate, keeps every other tenant secure, and surfaces the specific broken domain so it can be fixed.

How does one edge serve HTTPS for thousands of different domains?

Through Server Name Indication. The browser sends the requested hostname during the TLS handshake, and the edge selects the matching per-domain certificate from the many it holds.