HTTPS for Multi-Tenant SaaS: SNI, Wildcards

Building a multi-tenant SaaS platform introduces unique challenges when it comes to HTTPS. While a single-tenant application might use one certificate for one domain, multi-tenant systems must serve hundreds or thousands of different domains, each potentially with its own custom domain requirement.

This guide explores certificate strategies for SaaS applications that allow customers to use their own domains, covering SNI fundamentals, the tradeoffs between wildcard, SAN, and per-tenant certificates, how to issue certificates at scale, and best practices for secure key management.

Understanding the Multi-Tenant HTTPS Challenge

Most SaaS platforms start with a simple model: customers access their accounts through subdomains of your main domain. For example:

customer1.yourplatform.com

customer2.yourplatform.com

customer3.yourplatform.com

This approach works well initially because you can secure all customer subdomains with a single wildcard certificate for *.yourplatform.com. However, as your platform matures, customers often want to use their own domains:

app.customer1.com

portal.customer2.com

dashboard.customer3.com

Each customer domain requires its own valid SSL certificate, creating a scaling challenge. How do you provision, manage, and serve certificates for potentially thousands of different domains?

SNI: The Foundation of Modern Multi-Tenant HTTPS

Server Name Indication (SNI) is the technology that makes hosting multiple HTTPS sites on a single IP address possible. Understanding SNI is essential for implementing any multi-tenant certificate strategy.

How SNI Works

Before SNI, servers couldn't determine which certificate to present until after the TLS handshake completed. Since the server needed to present a certificate before knowing which hostname the client wanted, hosting multiple HTTPS sites on one IP address was problematic.

SNI solves this by having the client send the hostname it wants to reach during the initial TLS handshake, before encryption begins. The server uses this hostname to select the appropriate certificate.

The handshake flow looks like this:

Client initiates TLS connection and sends "Client Hello" including the hostname (via SNI)

Server examines the hostname from SNI

Server selects the appropriate certificate for that hostname

Server sends "Server Hello" with the chosen certificate

TLS handshake continues and secure connection establishes

SNI Browser Support

SNI has been supported by all modern browsers for over a decade. However, some very old clients don't support it:

Internet Explorer on Windows XP

Java 6 and earlier

Python 2.x (without specific libraries)

Some embedded devices and IoT hardware

For a modern SaaS platform, the percentage of users on SNI-incompatible clients is negligible. Most platforms can safely require SNI without concerns about accessibility.

SNI and Certificate Selection

With SNI, your server can host thousands of different domains on a single IP address, each with its own certificate. When a request arrives, the server:

Reads the SNI hostname from the TLS handshake

Looks up the corresponding certificate from its certificate store

Presents that certificate to the client

Routes the request to the appropriate tenant application

This capability makes multi-tenant HTTPS feasible, but you still need a strategy for obtaining and managing all those certificates.

Wildcard Certificates: The Simplest Approach

Wildcard certificates secure a domain and all its first-level subdomains using a single certificate.

When Wildcards Work Well

If all your customers use subdomains of your main domain (customer.yourplatform.com), a single wildcard certificate for *.yourplatform.com covers everyone. This approach is:

Simple to implement: One certificate to obtain, renew, and manage.

Cost-effective: One certificate regardless of customer count.

Easy to scale: Adding new customers requires no certificate provisioning.

Many hosting providers include wildcard certificates as part of their standard offerings, making this approach even simpler to implement.

Wildcard Limitations

Wildcards only cover one level of subdomains. A certificate for *.yourplatform.com covers customer.yourplatform.com but not app.customer.yourplatform.com. You'd need a separate wildcard for *.customer.yourplatform.com to cover that second level.

More significantly, wildcards don't help when customers want to use their own domains. A certificate for *.yourplatform.com won't secure app.customer.com.

Security Considerations

Wildcard certificates create a larger blast radius if compromised. If an attacker obtains your private key, they can impersonate any subdomain under your domain. This might be acceptable for customer subdomains, but it means your wildcard should never be used for different security contexts (like administrative systems or payment processing).

Subject Alternative Name (SAN) Certificates

SAN certificates can secure multiple specific domains within a single certificate. For example, one certificate might include:

app.customer1.com

portal.customer2.com

dashboard.customer3.com

site.customer4.com

Advantages of SAN Certificates

Fewer certificates to manage: Instead of one certificate per domain, you can consolidate multiple domains into single certificates.

Reduced overhead: Less certificate monitoring, fewer renewal operations, and simpler key management.

Practical Limitations

SAN certificates face several constraints that limit their usefulness for large-scale multi-tenant systems:

Size limits: Most certificate authorities limit SANs to around 100-250 domains per certificate. This means a platform with 1,000 customers still needs multiple certificates.

Rigid updates: Adding or removing a domain requires reissuing the entire certificate. If Customer 50 changes their domain, you must reissue a certificate containing all 100 domains in that SAN group.

Customer visibility: All domains in a SAN certificate are visible to anyone who examines the certificate. Some customers may object to their domain being listed alongside competitors.

Renewal coordination: You must renew the entire certificate even if only one domain needs updating, creating coordination challenges.

When SAN Makes Sense

SAN certificates work well for:

Small platforms with a manageable number of custom domains (under 50)

Internal tools where customer visibility isn't a concern

Situations where customers rarely change domains

Development or staging environments

For larger platforms or those with frequently changing domain requirements, SAN certificates become unwieldy.

Per-Tenant Certificates: Maximum Flexibility

Issuing individual certificates for each customer domain provides the most flexibility and scales to any size platform.

Benefits of Per-Tenant Certificates

Independent lifecycle: Each certificate can be issued, renewed, and revoked independently without affecting others.

Customer privacy: Customers' domains aren't visible in each other's certificates.

Flexible management: Add or remove customer domains instantly without coordinating with other tenants.

Isolated security: A compromised certificate affects only one customer.

The Automation Requirement

Managing individual certificates for thousands of customers is only practical with automation. Manual certificate procurement and renewal would be unmanageable at scale.

This is where ACME (Automatic Certificate Management Environment) protocol becomes essential.

ACME and Let's Encrypt

The ACME protocol, popularized by Let's Encrypt, allows automated certificate issuance and renewal. Understanding ACME is crucial for implementing per-tenant certificates at scale.

How ACME Works

ACME automates the certificate lifecycle through a challenge-response process:

Your server requests a certificate for a domain

The ACME server responds with a challenge to prove domain control

Your server completes the challenge

The ACME server verifies the challenge and issues the certificate

ACME supports several challenge types, but two are most relevant for multi-tenant SaaS:

HTTP-01 Challenge

The ACME server requests a specific file at a specific URL on your domain:

http://example.com/.well-known/acme-challenge/TOKEN

Your server must respond with the expected content to prove control of the domain.

Advantages:

Simple to implement

Works with standard HTTP servers

No DNS coordination required

Disadvantages:

Requires port 80 to be accessible

Can't be used for wildcard certificates

Requires HTTP infrastructure even for HTTPS-only applications

DNS-01 Challenge

The ACME server requests a specific TXT record in your domain's DNS:

_acme-challenge.example.com TXT "challenge-token"

You must create this DNS record to prove domain control.

Advantages:

Works for wildcard certificates

No HTTP infrastructure required

Can validate domains not publicly accessible

Disadvantages:

Requires DNS API access or coordination with DNS providers

DNS propagation delays can slow issuance

More complex to implement

Rate Limits and Considerations

Let's Encrypt imposes rate limits to prevent abuse:

50 certificates per registered domain per week

5 duplicate certificates per week

300 new orders per account per 3 hours

For multi-tenant platforms, these limits are usually sufficient, but you should implement retry logic and consider spreading certificate requests over time rather than bulk issuance.

Implementation Strategies

Strategy 1: Automated Per-Tenant with HTTP-01

This approach works well for platforms where all customer domains can point directly to your infrastructure:

Customer onboarding flow:

Customer adds their custom domain in your platform

Customer points their domain to your servers (via DNS A/AAAA records)

Your system detects the new domain configuration

Your ACME client requests a certificate using HTTP-01 challenge

Your server responds to the challenge at the appropriate path

Certificate issues and installs automatically

Customer's domain becomes accessible over HTTPS

Implementation requirements:

Web server configured to handle ACME challenge paths

Queue system for certificate requests to handle rate limits

Certificate storage and retrieval system

Automated renewal before expiration (Let's Encrypt certificates expire after 90 days)

Strategy 2: Automated Per-Tenant with DNS-01

This approach works when you need wildcard certificates for customers or when HTTP-01 isn't feasible:

Customer onboarding flow:

Customer adds their custom domain in your platform

Customer creates a CNAME record pointing to your domain or delegates DNS control

Your system uses DNS API to create challenge records

Your ACME client requests certificate using DNS-01 challenge

Certificate issues and installs automatically

Implementation requirements:

Integration with DNS provider APIs

Ability to create/delete TXT records programmatically

Handling for DNS propagation delays

Same certificate storage and renewal infrastructure as HTTP-01

Strategy 3: Hybrid Approach

Some platforms use wildcards for their own subdomains and per-tenant certificates for custom domains:

*.yourplatform.com covered by one wildcard

Each customer.com gets its own certificate via ACME

This reduces the total certificate count while still supporting custom domains.

Certificate Storage and Retrieval

With potentially thousands of certificates, efficient storage and retrieval becomes critical.

Storage Options

Filesystem: Store certificates and keys as files. Simple but requires careful permission management and doesn't scale well across distributed systems.

Database: Store certificates in your application database. Provides good querying capabilities but requires careful security for private keys.

Dedicated secret management: Use systems like HashiCorp Vault, AWS Secrets Manager, or similar. Provides security features like encryption at rest, access logging, and rotation capabilities.

Hybrid: Store certificate metadata in your database but private keys in dedicated secret management systems.

Retrieval Performance

Your web server needs fast certificate lookup during TLS handshake. Slow certificate retrieval delays connection establishment, harming user experience.

Caching: Keep frequently-accessed certificates in memory.

Indexing: Use hostname as the primary index for quick lookups.

Preloading: Load certificates into memory at application startup when possible.

Key Management Best Practices

Private keys must be protected carefully. Compromise of a private key allows attackers to impersonate your customers' domains.

Key Storage Security

Encrypt keys at rest: Never store private keys in plain text. Use encryption with strong key derivation functions.

Restrict access: Limit which systems and people can access private keys. Use role-based access control.

Audit access: Log all access to private keys for security monitoring.

Separate key storage: Don't store keys in the same database as application data.

Key Rotation

Regularly rotating private keys limits the impact of potential compromise:

Renewal rotation: Generate new private keys when renewing certificates, not just new certificates with the same key.

Incident response: Have procedures to quickly rotate keys for all customers if a breach is suspected.

Automated rotation: Build automated key rotation into your certificate renewal process.

Key Generation

Use strong entropy: Generate keys with cryptographically secure random number generators.

Appropriate key sizes: Use at least 2048-bit RSA keys or 256-bit ECDSA keys.

Secure generation location: Generate keys on secure systems, not customer-facing servers.

Handling Certificate Renewal

Let's Encrypt certificates expire after 90 days, requiring frequent renewal. Automation is mandatory.

Renewal Timing

Start renewal attempts 30 days before expiration. This provides ample time to handle failures and retry without service disruption.

Renewal workflow:

Monitor expiration dates for all certificates

Queue certificates for renewal 30 days before expiration

Attempt ACME renewal

On success, install new certificate

On failure, retry with exponential backoff

Alert operations if renewal fails repeatedly

Handling Renewal Failures

Certificates will occasionally fail to renew due to:

Temporary ACME server issues

DNS propagation delays

Customer domain configuration changes

Rate limit hits

Mitigation strategies:

Retry failed renewals with increasing delays

Alert customers when their domain configuration prevents renewal

Maintain fallback paths (like reverting to yourplatform.com subdomain)

Track renewal success rates to identify systemic issues

DNS Validation for Custom Domains

Before attempting certificate issuance, verify that customer domains are properly configured.

Pre-Flight Checks

When a customer adds a custom domain:

DNS resolution check: Verify the domain resolves to your servers

HTTP reachability: Confirm your servers can receive traffic for that domain

No conflicting certificates: Check if a certificate already exists for that domain

These checks prevent certificate issuance attempts that will fail, avoiding rate limits.

Customer Guidance

Provide clear documentation for customers configuring custom domains:

For A/AAAA records:

Type: A

Name: app

Value: 203.0.113.10

For CNAME records:

Type: CNAME

Name: app

Value: yourplatform.com

Many customers struggle with DNS configuration. Clear guidance reduces support burden and speeds onboarding.

Handling Certificate Revocation

Sometimes certificates need to be revoked before expiration:

Customer removes their custom domain

Private key compromise suspected

Domain ownership changes

Revocation Process

ACME supports certificate revocation:

Submit revocation request to ACME server

ACME server marks certificate as revoked

Remove certificate from your servers

Update certificate stores and caches

Cleanup Procedures

When customers remove custom domains:

Revoke associated certificates

Delete private keys securely

Remove DNS records if you control them

Archive relevant logs for compliance purposes

Monitoring and Alerting

Comprehensive monitoring ensures certificate issues get detected and resolved quickly.

Key Metrics to Track

Certificate expiration: Alert on certificates nearing expiration without successful renewal attempts.

Issuance failures: Track failed certificate requests and renewal attempts.

Issuance latency: Monitor time from request to successful issuance.

Rate limit consumption: Watch ACME API rate limit usage to avoid hitting limits.

Certificate errors: Track SSL/TLS errors from your web servers indicating certificate problems.

Customer-Facing Monitoring

Proactively notify customers about:

Upcoming certificate expirations requiring their action (if DNS is customer-managed)

Failed renewal attempts due to their domain configuration

Successfully issued/renewed certificates for transparency

Cost Considerations

While Let's Encrypt provides free certificates, operating a per-tenant certificate system has costs:

Infrastructure: Systems for certificate management, storage, and monitoring.

Development: Engineering time to build and maintain automation.

Operational overhead: Monitoring, troubleshooting, and customer support.

Alternative providers: Some platforms use paid certificate authorities for additional features like longer validity periods or insurance.

For most SaaS platforms, the flexibility and customer experience benefits of custom domains justify these costs, especially as automation reduces operational burden.

Scaling Considerations

As your platform grows, certificate management systems must scale accordingly.

Horizontal Scaling

Certificate issuance and renewal should be handled by worker processes that can scale horizontally:

Use message queues for certificate operation requests

Run multiple worker processes to handle queue

Distribute certificate operations across workers

Database Scaling

Certificate metadata storage must handle:

Thousands or millions of certificate records

Frequent queries during TLS handshakes (via caching)

Updates during issuance and renewal

Index appropriately on hostname and expiration date fields.

Caching Strategy

Implement multi-layer caching:

Memory cache: In-process cache for frequently accessed certificates

Distributed cache: Shared cache (like Redis) for cross-server consistency

Database: Authoritative source of truth

Alternative Certificate Authorities

While Let's Encrypt is popular for automation, other options exist:

Commercial CAs: Offer longer validity periods (1 year vs 90 days) and may include insurance or validation services.

ZeroSSL: Provides ACME-compatible automated certificates with some additional features.

Digicert, Sectigo, etc.: Traditional yet premium CAs with ACME support in some cases.

Consider alternatives when:

You need extended validation (EV) certificates

Longer validity periods reduce operational complexity

Compliance requirements mandate specific CAs

You want premium certificate insurance

Regulatory and Compliance Considerations

Depending on your industry, certificate management may face regulatory requirements:

Key Storage Compliance

Some regulations mandate specific key storage practices:

FIPS 140-2 compliance for cryptographic modules

PCI DSS requirements for certificate management

Industry-specific data protection regulations

Ensure your implementation meets applicable requirements.

Certificate Transparency

All publicly-trusted certificates are logged in Certificate Transparency (CT) logs. This means:

Issued certificates are publicly visible

Monitor CT logs to detect unauthorized certificate issuance for your customers' domains

Customers' domain names are publicly associated with your platform

This transparency is generally beneficial but may have privacy implications in sensitive industries.

Building a Robust System

Successful multi-tenant HTTPS implementation requires:

Solid automation: Manual processes don't scale. Invest in comprehensive ACME automation.

Thorough monitoring: Detect and resolve issues before customers notice.

Clear customer communication: Provide excellent documentation and proactive notifications.

Security-first design: Protect private keys rigorously and follow best practices.

Graceful degradation: Have fallback options when custom domains fail.

Regular testing: Periodically test issuance, renewal, and revocation processes.

Conclusion

Implementing HTTPS for multi-tenant SaaS platforms with custom domains requires careful architecture and robust automation. While wildcard certificates work well for subdomain-based multi-tenancy, custom domain support demands per-tenant certificates managed through ACME.

SNI enables serving thousands of different domains from shared infrastructure. ACME automation makes obtaining and renewing certificates practical at scale. Proper key management ensures security, while comprehensive monitoring prevents outages.

The complexity is significant, but the result is a professional SaaS offering that allows customers to use their own domains while maintaining security and reliability. With thoughtful implementation and ongoing operational discipline, multi-tenant HTTPS becomes manageable even at large scale.