In the previous articles of this series, we covered PKCS#12, timing oracles, lockout, and CSRF. All on an authentication service running mTLS. Let's talk about the TLS layer itself.

The service serves three distinct audiences: a web UI for end users (no client cert), an API for internal services (mTLS required), and an admin interface (mTLS required with different CAs). Three trust levels, one port.

One listener, three configs via SNI

The historical solution: three ports, three listeners, three tls.Config. Works, but triples the exposed network surface and complicates deployment (firewall rules, load balancer config, cert management).

The alternative: a single TLS listener with SNI-based routing (Server Name Indication). The client sends the hostname in the ClientHello, the server picks the matching TLS config — including the ClientAuth level.

func buildTLSConfig() *tls.Config {
    return &tls.Config{
        GetConfigForClient: func(hello *tls.ClientHelloInfo) (*tls.Config, error) {
            switch hello.ServerName {
            case "app.internal":
                return &tls.Config{
                    ClientAuth: tls.NoClientCert,
                    Certificates: []tls.Certificate{appCert},
                }, nil

            case "api.internal":
                return &tls.Config{
                    ClientAuth:   tls.RequireAndVerifyClientCert,
                    ClientCAs:    serviceCAPool,
                    Certificates: []tls.Certificate{apiCert},
                }, nil

            case "admin.internal":
                return &tls.Config{
                    ClientAuth:   tls.RequireAndVerifyClientCert,
                    ClientCAs:    adminCAPool,
                    Certificates: []tls.Certificate{adminCert},
                }, nil

            default:
                return nil, fmt.Errorf("unknown SNI: %s", hello.ServerName)
            }
        },
    }
}

Each audience gets its own server certificate, its own CA pool for client validation, and its own auth level. One open port.

The Host header vs SNI trap

SNI is in the TLS ClientHello. The Host header is in the HTTP request, after the handshake. Nothing forces them to match.

Without validation, a client can perform an SNI handshake toward app.internal (no client cert required) then send an HTTP request with Host: api.internal. If your HTTP router relies on the Host header for dispatch, the request reaches the API handler without mTLS.

The fix: middleware comparing SNI and Host, with a 421 Misdirected Request on mismatch:

func sniHostGuard(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        sni := r.TLS.ServerName
        host := r.Host
        // Strip port if present
        if h, _, err := net.SplitHostPort(host); err == nil {
            host = h
        }

        if host != sni {
            http.Error(w, "Misdirected Request", 421)
            return
        }
        next.ServeHTTP(w, r)
    })
}

Trade-offs vs multiple ports

Criterion

Multi-port

Multi-SNI

Network surface

3 open ports

1 port

Firewall rules

3 rules

1 rule

Certificates

1 cert per port (simple)

1 multi-SAN cert or 3 certs

Isolation

Strong (port = boundary)

Medium (code = boundary)

Deployment

More config

Simpler

Debugging

tcpdump per port

tcpdump + SNI filter

My take: multi-SNI is the right call when audiences share the same process and deployment lifecycle. If audiences have different lifecycles (independent scaling, different teams), separate ports are preferable.

Session cert binding: preventing cookie replay

Now for the second topic of this article: cert binding. The scenario: an attacker steals a session cookie (XSS, network interception, malware). They replay it on their own mTLS connection.

Without cert binding, the cookie is valid. The attacker has the victim's session. With cert binding, the server verifies that the client certificate presented in the handshake is the same one that created the session.

// At session creation
func createSession(r *http.Request, user *User) *Session {
    session := &Session{
        UserID:    user.ID,
        CreatedAt: time.Now(),
    }

    // Stamp the peer cert serial
    if r.TLS != nil && len(r.TLS.PeerCertificates) > 0 {
        session.CertSerial = r.TLS.PeerCertificates[0].SerialNumber.String()
    }

    return session
}

// On every authenticated request
func validateCertBinding(session *Session, r *http.Request) bool {
    if session.CertSerial == "" {
        return true // session created without cert (web audience)
    }

    if r.TLS == nil || len(r.TLS.PeerCertificates) == 0 {
        return false // session bound to a cert, but no cert presented
    }

    currentSerial := r.TLS.PeerCertificates[0].SerialNumber.String()
    return session.CertSerial == currentSerial
}

If the serial doesn't match: session rejected. This also covers cross-listener replay — a cookie stolen on the api.internal audience can't be used on admin.internal if the client certs are different.

Cert binding limitations

Let's be honest about what this doesn't cover:

• If the attacker has the cert's private key, binding is useless. But at that point, the attacker can authenticate fresh — binding isn't the bottleneck.
• Sessions without certs (web audience without mTLS) don't benefit from binding. For those, classic protections (HttpOnly, Secure, SameSite cookies) remain the only defense line.
• Cert rotation — when the user renews their cert, the serial changes. The session is invalidated. That's the intended behavior, but the renewal flow needs to be smooth.

Conclusion

Multi-SNI simplifies deployment without sacrificing auth level isolation, as long as you validate SNI == Host. Cert binding adds a protection layer against session theft that costs almost nothing in complexity — one extra field in the session, one extra check in middleware.

But mTLS has a problem that cert binding doesn't solve: what happens when a certificate is revoked and the client is already connected via TCP keep-alive? The handshake is done, the CRL has changed, but the client keeps serving. That's the subject of the next article.