Privacy & Security12 min
HTTPS for Multi-Tenant SaaS: SNI, Wildcards, and Per-Customer Certificates
NS
NameSilo Staff10/16/2025
Share
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.
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.
.png&w=2048&q=75)
NameSilo StaffThe NameSilo staff of writers worked together on this post. It was a combination of efforts from our passionate writers that produce content to educate and provide insights for all our readers.
More articleswritten by NameSilo
.png&w=3840&q=75)
.png&w=3840&q=75)
.png&w=3840&q=75)