SNI multi-certificate support, hot certificate reload, and inbound client mTLS

[janiussyafiq]

Description

A listener takes a single static certificate and key. There is no SNI-based selection among multiple certificates, no hot or graceful certificate reload without a process restart, and no inbound client-certificate verification with a configurable CA bundle — all mTLS in the tree is outbound (etcd client auth, control-plane heartbeat).

Requested:

• multiple certificates selected by SNI, including wildcards;
• hot reload on file change or control-plane push, with no restart and no dropped connections;
• optional inbound client mTLS with a CA bundle, a verification mode, and the client certificate subject/SAN available as a caller identity source.

Why

With 90-day ACME certificates, restart-to-rotate turns a routine automated job into scheduled downtime — and it is worse here than on a typical gateway, because the traffic is long-lived streaming SSE and WebSocket sessions that a restart severs mid-response. Inbound mTLS is routine for service-to-service traffic inside enterprises.

The workaround for all three is terminating TLS at another proxy in front, which defeats a single-gateway deployment.

Priority

Medium.

---

Prior art

Product	Has it	Reference
LiteLLM	Partial	--ssl_keyfile/--ssl_certfile only
Portkey	No	defers to the proxy
Kong AI Gateway	Yes	SNI entity + Admin API cert CRUD + mTLS
Cloudflare AI Gateway	No	managed endpoint
Bifrost	No	defers to the proxy
Envoy AI Gateway	Yes	SNI cert selection + mTLS
Apache APISIX	Yes	snis + dynamic SSL objects + mTLS

Table stakes for general-purpose gateways; LLM-native gateways mostly do not own the listener.

_{Surveyed 2026-07-15; every claim rests on a fetched docs/source page.}