On a server hosting multiple sites/domains on one IP address, SSL problems specific to this setup usually trace back to SNI configuration — the mechanism that lets the server determine which certificate to present based on the hostname the client is requesting, before the encrypted connection is fully established.
Common failure patterns
- A "default" server block inadvertently catching requests intended for a different, more specific hostname's block
- A newly added domain's server block missing entirely, causing requests for it to fall through to an unrelated default certificate
- A very old client that doesn't support SNI at all, receiving whatever certificate is configured as the server's default rather than the one for its intended hostname — a in practice rare issue today given how widely SNI is supported
Diagnosing
Test each hostname explicitly with openssl s_client -servername specific-hostname.com -connect server-ip:443, which lets you confirm exactly which certificate is being returned for each specific hostname independently, rather than relying on DNS already pointing correctly (which can itself be a separate, confounding variable).
What makes multi-tenant SSL configuration exactly prone to this class of issue
A server or platform hosting many different customers' domains on shared infrastructure has considerably more opportunity for an SNI misconfiguration to affect one specific tenant while others remain unaffected, compared to a single-site server where a misconfiguration would be immediately obvious across all traffic.
How platform operators can systematically audit for this across many tenant domains
Scripting a loop that tests SNI-based certificate selection for every hosted tenant domain individually, rather than spot-checking a handful, catches an isolated misconfiguration affecting one specific tenant among many that a general platform health check might otherwise miss entirely.
What a specific real-world example of a multi-tenant SNI failure looks like
A SaaS platform hosting hundreds of customer-provided custom domains on shared infrastructure, where one specific customer's domain was added without its corresponding certificate being properly registered in the SNI routing configuration, is a textbook example — the platform works correctly for every other tenant, isolating the issue to that one specific, incompletely configured domain.
How automated certificate provisioning systems reduce this risk at scale
A fully automated certificate provisioning pipeline, where adding a new tenant domain automatically triggers certificate issuance and SNI configuration as a single, atomic process, considerably reduces the risk of the kind of partial, inconsistent configuration that causes this class of issue compared to manually managing certificates for each new tenant individually.
What the exact testing approach looks like for auditing many tenant domains systematically
Scripting a loop using OpenSSL's -servername flag against every tenant domain in your platform's database, checking that each one returns its own specific, correct certificate rather than a default or unrelated one, systematically catches isolated misconfigurations a manual, sample-based check would likely miss.
How to build automated alerting specifically for this class of issue at scale
Integrating your systematic tenant-domain testing script into a scheduled job with alerting on any detected mismatch turns a one-time audit into ongoing, automated protection against this class of issue recurring as new tenants are added over time.
What role customer self-service domain verification plays in preventing this issue upstream
A platform requiring customers to complete a clear domain verification and certificate provisioning confirmation step themselves, rather than relying entirely on internal automation working correctly every time, adds a valuable additional check that can catch a provisioning gap before it becomes a live, customer-facing issue.
See RFC 6066, the TLS extensions spec defining SNI.
Loading comments…