SSL Certificates for SaaS Applications: What Multi-Tenant Platforms Actually Need

SSL certificate management for a single website is straightforward: buy or provision a certificate, install it, set up renewal. SSL certificate management for a SaaS platform with thousands of customer tenants is an entirely different engineering problem.

When a SaaS platform supports custom domains (allowing customers to serve the platform from their own domain rather than a subdomain of the platform), each customer domain needs its own SSL certificate. At 1,000 customers, you need 1,000 certificates. At 50,000 customers, you need 50,000. The issuance, storage, renewal, and serving of this certificate fleet cannot be manual. It requires automated infrastructure that most conventional SSL guides do not address.

This guide covers the architectural patterns used by production SaaS platforms, the technical mechanisms that make per-tenant certificates viable, the services available to SaaS builders for handling this problem, and the operational considerations that become critical at scale.

The Three Tenant Domain Patterns and Their SSL Implications

The SSL approach for a SaaS platform depends fundamentally on which domain model the platform supports.

Pattern 1: Subdomain per tenant (tenant.yourplatform.com)

Each tenant gets a subdomain of the platform’s root domain. customer1.yourplatform.com, customer2.yourplatform.com, and so on. The SSL coverage for all tenants is provided by a single wildcard certificate for *.yourplatform.com. Certificate management is simple: one certificate, one renewal, no per-tenant work.

This pattern covers the vast majority of SaaS platforms in terms of simplicity. The platform needs exactly two certificates: one for yourplatform.com and www.yourplatform.com, and one wildcard for *.yourplatform.com. The wildcard covers all tenant subdomains automatically.

The limitation is branding and white-labeling. Some customers want their own domain (shop.customerbrand.com) rather than a subdomain of the platform. Platforms without custom domain support cannot serve this need. For many B2B SaaS products this is acceptable; for e-commerce platforms, website builders, and other customer-facing tools it is often a product requirement.

Pattern 2: Custom domains via CNAME delegation

Each tenant points their own domain to the SaaS platform via a DNS CNAME record. The customer adds shop.customerbrand.com CNAME yourplatform.com (or a dedicated hostname like cname.yourplatform.com) in their DNS. The platform receives requests for shop.customerbrand.com and must serve them with a valid SSL certificate for that domain.

This is the technically complex pattern that requires per-tenant certificate infrastructure. The platform cannot use its own wildcard certificate for customer-owned domains. Each customer domain needs its own certificate, issued for that specific domain, served via SNI when connections arrive.

Shopify, Webflow, Netlify, Vercel, Ghost Pro, HubSpot CMS, and virtually every modern website or e-commerce SaaS that supports custom domains uses this pattern. The certificate infrastructure behind it is a significant engineering investment.

Pattern 3: Hybrid

The platform provides a subdomain under the platform domain as a default (covered by the wildcard), and optionally allows customers to configure a custom domain. Most customers use the default; custom domains are available for those who need them. The SSL complexity exists only for customers who have configured custom domains.

This is the pragmatic pattern for SaaS platforms where custom domains are a premium feature or are used by a minority of customers. The engineering cost of certificate automation exists but applies to a smaller fraction of tenants.

Server Name Indication: How One Server Serves Thousands of Certificates

The technical mechanism that makes multi-tenant certificate serving possible is Server Name Indication (SNI), a TLS extension that has been in universal use since approximately 2016.

Before SNI, the TLS handshake happened before the server knew which virtual host the client was connecting to. The server had to present its certificate before receiving the HTTP request that would identify the target hostname. This meant each HTTPS-enabled hostname needed its own IP address (or its own physical server), since the server could not determine which certificate to serve before the TLS negotiation.

SNI allows the client to include the target hostname in the first TLS message (the ClientHello). The server reads the SNI value, selects the appropriate certificate for that hostname, and proceeds with the TLS handshake. One IP address can now serve thousands of different certificates, one for each hostname, with the certificate selection happening at the start of each connection based on the SNI value.

Every modern browser and HTTP client supports SNI. The last meaningful holdout was Internet Explorer on Windows XP, which did not support SNI. Windows XP reached end of life in April 2014 and IE on XP has effectively zero usage. SaaS platforms can rely on SNI without reservation for any production use case.

SNI is why modern platforms like Vercel, Netlify, and Cloudflare can serve custom domain certificates for millions of sites from a shared edge infrastructure. Each incoming TLS connection announces its target hostname before the TLS handshake completes. The edge infrastructure looks up the certificate for that hostname, serves it, and completes the connection. The same edge server handles thousands of different domains simultaneously.

The Domain Validation Challenge for Customer-Owned Domains

Issuing a certificate for customer-owned domain shop.customerbrand.com requires proving control of that domain. The platform does not own the domain. The customer does. This creates a fundamental challenge: standard domain validation methods require either serving a specific file from the domain (HTTP-01 challenge) or adding a specific DNS record to the domain (DNS-01 challenge).

For a SaaS platform provisioning certificates for customer domains at scale, neither standard method works without customer involvement at each issuance. Requiring customers to add DNS records every time a certificate needs to be provisioned or renewed is operationally impractical and creates an unacceptable customer experience.

The CNAME delegation solution for DNS-01

The solution used by every major SaaS platform for automated certificate provisioning is CNAME delegation for DNS-01 validation. It works as follows:

When a customer adds a custom domain to the platform, the platform instructs them to add two DNS records: a CNAME pointing their domain to the platform (shop.customerbrand.com CNAME cname.yourplatform.com), and a CNAME for the ACME DNS challenge subdomain pointing to the platform’s DNS validation infrastructure (_acme-challenge.shop.customerbrand.com CNAME validation.yourplatform.com).

The customer adds these CNAMEs once, at setup time. From that point, whenever the platform needs to issue or renew a certificate for shop.customerbrand.com, it creates the appropriate DNS TXT record at validation.yourplatform.com (which the platform controls), the ACME CA resolves the _acme-challenge.shop.customerbrand.com CNAME to validation.yourplatform.com, finds the TXT record, and validates the challenge. The platform has effectively delegated DNS control for the challenge subdomain to itself through the CNAME.

The customer never touches DNS again. Certificate issuance and renewal happen automatically without any customer involvement.

The two-CNAME setup (one for traffic routing, one for ACME challenges) is the standard onboarding step for custom domains on SaaS platforms. Customers who configure custom domains on Shopify, Webflow, Netlify, or similar platforms are performing exactly this setup, often without realizing the ACME challenge CNAME is there. The platform’s documentation typically describes it as part of domain verification rather than explaining its certificate automation role.

HTTP-01 alternative

For platforms where the customer’s traffic already routes through the platform (via the traffic-routing CNAME), HTTP-01 validation is also possible: the ACME client places a challenge file at a specific URL path (/.well-known/acme-challenge/TOKEN), and the CA retrieves it. Because the CNAME routes all traffic through the platform, the platform can serve this challenge file for any customer domain.

HTTP-01 is simpler to implement than DNS-01 but has a limitation: it cannot validate wildcard certificates. For platforms that need to issue wildcard certificates for customer subdomains (for example, if customers can have their own sub-subdomains), DNS-01 is required. For platforms issuing single-domain certificates for each customer domain, HTTP-01 is a viable and simpler alternative.

Certificate Infrastructure Options for SaaS Platforms

Three primary approaches exist for a SaaS platform building custom domain certificate support.

Option 1: Build your own ACME automation

The platform implements an ACME client that issues certificates from Let’s Encrypt (or another ACME CA) for each customer domain as they are configured, stores the certificates and private keys in a secure certificate store, serves them via SNI on the platform’s edge or load balancer layer, and runs automated renewal for each certificate 30 days before its 90-day expiry.

This approach provides maximum control and no per-certificate fees. Let’s Encrypt is free, and the only costs are infrastructure: storage, compute for the ACME client, and the engineering time to build and operate the system reliably. The operational complexity is substantial: certificate storage at scale, renewal job infrastructure, handling Let’s Encrypt outages, managing rate limits, serving certificates via SNI across a distributed edge, and handling error cases for certificates that fail to renew.

Let’s Encrypt rate limits for ACME account usage relevant to SaaS: 300 new orders per 3-hour window per ACME account, and 10 failed validations per domain per hour. At large scale (tens of thousands of new customer domains per day), a single ACME account hits the 300-order limit and requires multiple accounts or staggered issuance. Most large SaaS platforms either build account pooling or use a managed service.

Option 2: Cloudflare for SaaS

Cloudflare for SaaS (previously called Cloudflare SSL for SaaS) is a dedicated product for this use case. SaaS platforms configure Cloudflare with their platform hostname, and when a customer domain is added, the platform calls Cloudflare’s API to create a Custom Hostname. Cloudflare handles certificate issuance (using its own CA or Let’s Encrypt), renewal, and SNI serving through its global edge network.

The platform’s customers add their CNAME pointing to the platform (routed through Cloudflare), and Cloudflare issues and manages the certificate for each customer domain automatically. The pricing model is per-custom-hostname per month, which makes it cost-effective at moderate scale and predictable at large scale.

Cloudflare for SaaS is the approach used by many mid-market SaaS platforms that want to support custom domains without building certificate automation infrastructure internally. The trade-off is dependency on Cloudflare’s infrastructure and the per-hostname cost at large scale.

Option 3: AWS services (ACM + API Gateway or CloudFront)

AWS offers two related paths. API Gateway custom domains use ACM certificates requested per domain via the ACM API; the API call triggers domain validation and the certificate is automatically provisioned and served. CloudFront with ACM follows the same pattern but requires certificates in us-east-1.

For SaaS platforms heavily invested in AWS infrastructure, these services integrate naturally with the rest of the stack. ACM certificates are free and auto-renewing within AWS. The limitation is that customer domains require ACM certificate requests (which take minutes to hours), and the custom domain setup in API Gateway or CloudFront must also be created programmatically for each customer. This is fully automatable via AWS SDKs but requires more infrastructure setup than Cloudflare for SaaS.

Certificate Infrastructure Approaches: Comparison

Operational Considerations at Scale

Certificate storage and key management

Each customer domain certificate requires storage for the certificate chain and private key. At 50,000 custom domains, the certificate store grows substantially. Keys must be stored securely (encrypted at rest, with access controls), accessible to the SNI serving layer with low latency, and manageable for rotation after certificate renewal.

Secrets management systems (AWS Secrets Manager, HashiCorp Vault, Google Cloud Secret Manager) handle certificate storage at scale with appropriate security controls. The SNI serving layer retrieves certificates by hostname on each new TLS connection or caches them in memory with TTL-based invalidation after renewal.

Renewal at scale

Let’s Encrypt certificates are valid for 90 days. Standard practice is to renew starting at 30 days before expiry. For a platform with 100,000 customer domains, this means roughly 33,000 renewal operations per month, or approximately 1,100 per day on average. The renewal pipeline must handle this steadily without batch spikes that hit rate limits.

Staggering renewals (distributing renewal attempts across the day) prevents rate limit issues and avoids the risk of a renewal failure affecting all certificates that expire on the same date. Certificates issued at different times naturally stagger, but a platform that onboards a large cohort of customers simultaneously will have a batch of certificates all expiring 60 days later. Account for this in renewal infrastructure design.

The DV-only constraint for automated issuance

Every automated certificate issuance system (Let’s Encrypt, ACM, Cloudflare for SaaS) issues only Domain Validated (DV) certificates. DV requires only domain control verification, which can be fully automated. OV and EV certificates require human-reviewed identity verification (legal entity, phone, address) that cannot be automated for thousands of customer domains owned by different organizations.

For SaaS platforms, customer-facing HTTPS always uses DV certificates on customer custom domains. If a customer requires OV or EV on their custom domain for compliance reasons, they must obtain and manage that certificate themselves and somehow provide it to the platform, which most platforms do not support. When evaluating whether your SaaS product needs to support customer-specified certificate types, the answer for most platforms is no: DV is appropriate and sufficient for the encrypted connection provided to end users.

Handling certificate provisioning failures

Certificate issuance can fail: the customer’s CNAME is not yet propagated, the DNS challenge CNAME is misconfigured, the domain is temporarily unreachable, or Let’s Encrypt has a brief service interruption. Production platforms need robust handling for these cases: retry queues with exponential backoff, alerting for domains that have been failing to issue for more than a defined period, and customer-facing status for their domain certificate state.

The customer experience during provisioning also matters. Between when a customer adds their custom domain and when the certificate is issued (minutes to hours depending on DNS propagation), their domain may show SSL errors if the platform serves traffic before the certificate exists. Some platforms show a pending state and delay serving traffic on the custom domain until the certificate is confirmed. Others serve a generic page. The handling of this gap is a product decision with SSL implications.

Should You Issue Wildcard Certificates for Tenants?

Some SaaS platforms issue wildcard certificates for customer domains rather than single-domain certificates. If a customer wants their own domain and subdomains (shop.customerbrand.com and www.shop.customerbrand.com and api.shop.customerbrand.com), a wildcard certificate for *.customerbrand.com covers all of them.

Wildcard certificates for customer domains via ACME require DNS-01 validation. HTTP-01 cannot validate wildcards. The DNS-01 CNAME delegation must be set up at the apex domain level (_acme-challenge.customerbrand.com rather than _acme-challenge.shop.customerbrand.com).

The security consideration: a wildcard certificate compromise (private key theft) affects all subdomains of the customer’s domain. If the platform’s certificate storage is breached, all customers’ wildcard certificates are compromised simultaneously. Individual per-subdomain certificates limit blast radius but increase certificate volume. Most platforms choose per-domain certificates to limit blast radius, accepting the higher certificate volume.

Frequently Asked Questions

How do SaaS platforms issue SSL certificates for thousands of customer domains?

Through automated ACME certificate issuance, typically from Let’s Encrypt. When a customer adds a custom domain to the platform, the platform’s certificate automation system issues a certificate for that domain using the ACME DNS-01 challenge via CNAME delegation. The customer adds a CNAME pointing the ACME challenge subdomain to the platform’s DNS infrastructure at setup time. After that, the platform can issue and renew certificates for the customer’s domain fully automatically without further customer involvement.

Why can SaaS platforms only issue DV certificates for customer domains?

Automated certificate issuance supports only Domain Validation (DV), which verifies domain control through automated challenges. OV and EV certificates require human-reviewed identity verification of the organization or individual behind the domain: legal entity confirmation, address verification, phone verification against independent databases. This process cannot be automated for thousands of different organizations each owning different customer domains. DV is appropriate for providing encrypted HTTPS connections to end users; the platform’s own certificates (for the platform domain and admin interfaces) can be OV or EV.

What is SNI and why does it matter for multi-tenant SSL?

Server Name Indication is a TLS extension that allows a client to announce which hostname it is connecting to at the start of the TLS handshake, before any HTTP request is sent. This allows a single server with one IP address to host thousands of HTTPS sites, selecting the appropriate certificate for each connection based on the announced hostname. Without SNI, each HTTPS hostname required a dedicated IP address, making multi-tenant custom domain SSL architecturally impractical. SNI has been universally supported in browsers since 2016 and is the foundational technology enabling custom domain SSL on SaaS platforms.

What is the easiest way to add custom domain SSL to a SaaS platform?

Cloudflare for SaaS (the custom hostnames product) is the lowest-engineering-effort option for adding custom domain certificate support to a SaaS platform. The platform configures Cloudflare as its DNS provider and CDN, and uses the Cloudflare API to create custom hostnames for each customer domain. Cloudflare handles certificate issuance, renewal, and SNI serving. The trade-off is a per-hostname monthly cost and dependency on Cloudflare infrastructure. For platforms wanting to avoid third-party dependency, building ACME automation with Let’s Encrypt provides full control at the cost of significantly more engineering investment.