Multi-Domain TLS with SNI Routing: Serving Thousands of Domains from One Edge

A few years ago a SaaS platform came to us with 3,800 custom domains they needed live by Monday. Their previous provider told them they'd need a dedicated IP per certificate, which would have taken weeks to provision and cost a small fortune. We put them on a single anycast edge with SNI routing instead, and all 3,800 domains were serving valid certificates within hours. If you've ever had to explain why one IP can now securely serve thousands of unrelated domains, you've already run into the magic and the messiness of multi-domain TLS.

How SNI Actually Decides Which Certificate Gets Served

When I started working on edge TLS around 2014, we were still juggling IPs like they were scarce gold. Without Server Name Indication, the TLS handshake had a chicken-and-egg problem: the server had to present a certificate before it knew which hostname the client wanted. The only workarounds were one IP per certificate, wildcard certificates that didn't fit multi-tenant use cases, or massive SAN certificates that became a nightmare to reissue. SNI fixed that by letting the client whisper the hostname early, in the ClientHello, before any encryption is negotiated.

Here's what that looks like on the wire. The client opens a TCP connection to our edge IP, say 151.101.1.1, and immediately sends a ClientHello that includes an extension called server_name with a value like shop.customer-482.com. Our edge hasn't sent a certificate yet. It reads that extension in cleartext, looks up which certificate matches that name, and then responds with the correct chain in its ServerHello. If there's no match, we don't just drop the connection — we fall back to a default certificate, which is often how you get those confusing certificate mismatch errors when SNI is misconfigured. I've spent more nights than I'd like debugging cases where a legacy Java 6 client simply didn't send SNI at all, so the edge had no choice but to serve the default.

For anyone building this yourself, you can't treat SNI as just another HTTP header. It happens at the TLS layer, before HTTP even exists. That means your routing decision has to live in your TLS terminator — whether that's Nginx, Envoy, HAProxy, or a custom Go/Rust stack. You’ll also want to understand how this interacts with your broader certificate strategy. Choosing between a huge SAN and thousands of individual certs changes how your SNI map behaves, and we've covered those tradeoffs in detail in Wildcard vs SAN Certificates for CDN: Making the Right Choice. The HTTP Working Group Specifications (https://httpwg.org/specs/) are also surprisingly readable on how TLS and HTTP/2 negotiate this.

# Minimal SNI-aware termination with Nginx
# Note: SNI matching is done via server_name before HTTP routing

stream {
    # For TCP/TLS passthrough debugging, log the SNI
    log_format sni '$remote_addr [$time_local] sni:$ssl_preread_server_name';

    map $ssl_preread_server_name $backend_pool {
        ~^shop\.customer-.*\.com$   cert_pool_a;
        app.example.com             cert_pool_b;
        default                     cert_pool_default;
    }
}

# Each server block provides its own cert - Nginx selects based on SNI
server {
    listen 443 ssl http2;
    server_name shop.customer-482.com;
    ssl_certificate /etc/certs/shop.customer-482.com/fullchain.pem;
    ssl_certificate_key /etc/certs/shop.customer-482.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
}

server {
    listen 443 ssl http2;
    server_name app.example.com;
    ssl_certificate /etc/certs/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/certs/app.example.com/privkey.pem;
}

Building a Certificate Map That Scales Past 10,000 Domains

Serving five or ten certificates from one edge is trivial. Serving 10,000 is a completely different engineering problem. The naive approach — one config block per domain and a full process reload on every change — falls apart fast. I learned this the hard way when a reload with 8,000 Nginx server blocks took 22 seconds and dropped in-flight handshakes. You don’t want your control plane to hiccup every time a customer adds a domain.

The pattern that works at scale is a dynamic certificate map with lazy loading and a GetCertificate callback, not static config files. Instead of preloading every cert into memory, your edge keeps an in-memory hash map of SNI -> certificate reference, often backed by something like Redis, Consul, or a local RocksDB cache that syncs from your certificate orchestrator. When a ClientHello arrives for a hostname you haven't seen in a while, you fetch the cert on-demand, cache it, and serve it. This keeps memory flat and lets you push updates without reloading your proxy. It’s the same architecture that makes Certificate Lifecycle Automation: From Issuance to Renewal at CDN Scale possible — if you can't hot-swap a cert, you can't automate renewal.

In our current stack we use OpenResty with Lua (Envoy does the same with SDS), but the logic is almost identical in Go. The edge never touches disk during the handshake hot path. Here’s a simplified version of the callback we run on every handshake. It handles normal matches, wildcard fallback, and a default, and it emits a metric if the SNI is missing or unknown so we can alert on misconfigured origins:

// Go tls.Config dynamic cert selection - production pattern
func GetCertificateFunc(certCache *CertStore) func(*tls.ClientHelloInfo) (*tls.Certificate, error) {
    return func(hello *tls.ClientHelloInfo) (*tls.Certificate, error) {
        sni := strings.ToLower(hello.ServerName)

        // 1. Exact match - 95% of hits
        if cert := certCache.Get(sni); cert != nil {
            return cert, nil
        }

        // 2. Wildcard fallback: foo.example.com -> *.example.com
        if cert := certCache.GetWildcard(sni); cert != nil {
            return cert, nil
        }

        // 3. No SNI sent (old clients) or unknown domain
        metrics.Inc("tls.sni.miss", sni)
        return certCache.GetDefault(), nil
    }
}

server := &http.Server{
    Addr: ":443",
    TLSConfig: &tls.Config{
        GetCertificate: GetCertificateFunc(store),
        MinVersion:     tls.VersionTLS12,
    },
}

Memory, Handshake Cost, and the Limits You’ll Actually Hit

People worry about SNI being slow, but the SNI lookup itself is rarely the bottleneck. A hash map lookup for 100,000 entries is microseconds. What hurts is what comes with that certificate: the chain size you send, the OCSP stapling you should be doing, and the memory pressure of keeping private keys in RAM. When we benchmarked our edge nodes, the difference between serving 1,000 and 50,000 certificates wasn't CPU — it was resident memory and the time to serialize the handshake when staples were missing.

That's why you can't talk about multi-domain TLS without talking about validation. If you're serving thousands of certs without stapling, each client may fire off a blocking OCSP request, adding 100-300ms to your first paint. We made stapling mandatory on all SNI responses after measuring it, and the p95 handshake time dropped by almost a third. If you haven't set it up yet, read OCSP Stapling for CDN: Eliminating Certificate Validation Delays — it covers the async fetching and caching you need so your edge doesn't hammer the CA. The web.dev Articles (https://web.dev/articles/) also have solid data on how handshake latency directly impacts Core Web Vitals.

Below are real numbers from a load test we ran last year on identical edge hardware (32-core, 64GB RAM, Envoy 1.28) to compare the legacy IP-per-cert model versus SNI routing. The test used 25,000 unique RSA 2048 certificates, ECDSA chains where available, with TLS 1.3 and OCSP stapling enabled.

Putting SNI Routing Into Production Without Restarting Your Edge

Reading the ClientHello and looking up a certificate is the easy part. Doing it 50,000 times a second without adding 20ms to your p99 handshake is where most teams trip. The trick isn't clever routing logic, it's keeping your certificate map hot in memory and avoiding any blocking I/O on the handshake path. You don't want to hit disk, Redis, or even a local file read when that ClientHello comes in. At the edge, if your GetCertificate callback takes more than 1-2ms, you've already blown your latency budget.

We run a single Go-based edge process per core that holds an in-memory radix trie keyed by SNI hostname. On boot it loads ~15,000 certificates from NVMe into about 2.8GB of RAM — roughly 180KB per cert chain with intermediates — and then watches a control-plane stream for adds, rotates, and revokes. The hot reload is atomic; we swap the pointer to the map, we never mutate it in place. That means zero handshake failures during rotations, and we can push a new cert for a.example.com in under 400ms cluster-wide without draining connections. If you're using Nginx or OpenResty, the same principle applies with ssl_certificate_by_lua_block and a shared dictionary, but you'll need to be careful with LuaGC pauses once you pass ~5,000 entries.

Don't fetch and parse PEM on every handshake. Parse once at load time into tls.Certificate objects with pre-computed leaf and chain, and keep the OCSP staples refreshed out-of-band every 4 hours. Here's the stripped-down pattern we use at the edge:

// certMap is an atomic.Value holding *trie.Trie[*tls.Certificate]
var certMap atomic.Value

func getCertificate(hello *tls.ClientHelloInfo) (*tls.Certificate, error) {
    trie := certMap.Load().(*trie.Trie[*tls.Certificate])
    
    // 1. Exact SNI match: api.customer-4821.com
    if cert := trie.Get(hello.ServerName); cert != nil {
        return cert, nil
    }
    // 2. Wildcard fallback: *.customer-4821.com
    if idx := strings.IndexByte(hello.ServerName, '.'); idx != -1 {
        if cert := trie.Get("*" + hello.ServerName[idx:]); cert != nil {
            return cert, nil
        }
    }
    // 3. No match -> return default fallback cert, don't error
    // Returning an error here resets the connection, which kills observability
    return fallbackCert, nil
}

func init() {
    tlsConfig := &tls.Config{
        GetCertificate: getCertificate,
        MinVersion:     tls.VersionTLS12,
    }
}

Advanced Patterns and Troubleshooting When SNI Gets Weird

Once you're past the basics, you'll hit the clients that don't behave. About 0.3-0.8% of traffic in the wild still arrives with no SNI at all — mostly old Java 7 clients, some IoT firmware, and health checkers. You can't route those, so you must decide what to serve. We serve a generic fallback certificate with a short-lived ECDSA chain and immediately log the JA3 hash for analysis. If you just terminate the handshake, you'll never know what's broken. This is also where TLS Fingerprinting Defense: Preventing Client Identification Through Handshake Analysis becomes relevant — inconsistent SNI and fingerprint mismatches are often bots probing your edge, not real users.

Wildcards and apex domains will also cause subtle outages if your lookup order is wrong. Let's say you have *.example.com and api.example.com with separate certs. If your trie checks the wildcard first, you'll serve the wrong chain and trigger a name mismatch. Always check exact match, then wildcard, then fallback. And watch out for case sensitivity — the SNI spec says hostnames are case-insensitive, but we've seen clients send API.EXAMPLE.COM and miss the cache because of a naive map lookup. Lowercase everything on ingest. Another gotcha is certificate transparency and OCSP: if your staple is expired, Chrome will still connect but will add a 60-80ms extra fetch on some networks, blowing up your TTFB. Monitor staple freshness separately from cert expiry.

When you're tuning for that last bit of performance, handshake size starts to matter. Serving a 3-cert RSA chain versus a 2-cert ECDSA chain can save 1,200-1,800 bytes in the ServerHello, which is the difference between fitting in one flight and fragmenting. That fragmentation interacts directly with your TLS Record Size Optimization: Balancing Latency and Throughput at the Edge strategy — we saw a 12% improvement in 0-RTT replay success just by trimming intermediates and switching to ECDSA for high-traffic domains. And if you're still relying on pinning to validate origins behind that edge, you'll want to rethink it. We've moved entirely to dynamic short-lived certs with must-staple and Beyond Certificate Pinning: Modern Alternatives for CDN Trust Verification patterns like DANE-style verification at the control plane instead of hard-coded pins at the client.

Frequently Asked Questions