Native TLS web server: support SNI / multiple certificates on a single :443 listener

[logbie]

Summary

The native TLS web server (listen on port 443 secured with certificate <cert> and key <key>) binds a single certificate/key per listener and has no SNI support — it cannot select a certificate based on the TLS ClientHello server name. This means one WFL process can serve HTTPS for only one certificate on :443.

Current behavior

• In src/interpreter/mod.rs, the secured listener builds a rustls ServerConfig from one PEM chain + one key (single-cert). There is no ResolvesServerCert / SNI resolver, and two secured listeners cannot both bind :443.
• A request arriving with a different SNI still gets the one loaded certificate, so any other hostname fails validation.

Why it matters (real deployment)

This surfaced deploying wfl-web (the WFL site, now the Scriptorium CMS) on a single box that needs to serve wfl.fyi (behind Cloudflare, using a Cloudflare Origin cert) while also answering for the retired webfirstlanguage.com to 301-redirect it. With only one cert per :443, the box cannot present a valid cert for both names at once. The workaround was to move the old domains onto Cloudflare and redirect at the edge — but a WFL server that terminates its own TLS for multiple hostnames (e.g. apex + a redirect domain, or multi-tenant sites) has no in-language option today.

Proposed

Add SNI / multi-certificate support to the secured web server, e.g.:

• Allow multiple listen ... secured with certificate <cert> and key <key> bindings on the same port, selected by SNI; or
• A cert-map form, e.g. listen on port 443 secured with certificates cert_map as web_server where cert_map maps hostname -> {cert, key}; or
• Wire a rustls ResolvesServerCert behind the existing syntax so multiple certs can be registered.

A sensible default (first/only cert as fallback for unmatched SNI) would keep single-cert setups unchanged.

Environment

• WFL 26.7.27 (also present on 26.7.21), native TLS web server, rustls.
• Reported from the wfl.fyi / webfirstlanguage.* deployment on the hostinger box.

[logbie]

Assessment: confirmed enhancement — SNI is blocked by warp's TLS wrapper, not by our config plumbing

Verified against main (e4e34fc, v26.7.32). The report is accurate, and the constraint is a little sharper than "we only load one cert":

Root cause. The secured listener in src/interpreter/mod.rs (~L5640–5715) resolves a single cert_path/key_path (from the listen statement, falling back to web_server_tls_cert_file / web_server_tls_key_file in .wflcfg), validates them via validate_tls_pem_files, and then hands them straight to warp:

warp::serve(routes).tls().cert_path(&cert_path).key_path(&key_path)
    .try_bind_with_graceful_shutdown((bind_addr, port_num), std::future::pending::<()>())

warp 0.3.7's TlsServer builder is the whole problem: it constructs the rustls ServerConfig internally with a single cert chain + key and exposes no hook for a rustls::server::ResolvesServerCert. Grepping the tree confirms we never touch rustls::ServerConfig ourselves — rustls only reaches us transitively (via warp's tls feature and sqlx's runtime-tokio-rustls); the only direct dependency is rustls-pemfile. So no amount of WFL-side syntax gets us SNI while TLS termination lives inside warp::serve().tls(). Separately, two secured listeners on :443 would collide at bind time — there's no port registry to multiplex them — so the "multiple listen bindings" option in the proposal is the most invasive of the three.

Fix shape (my recommendation). Terminate TLS ourselves and keep warp as the request handler:

1. Build a rustls::ServerConfig with .with_cert_resolver(Arc::new(WflSniResolver { ... })), where the resolver maps the ClientHello server_name() to a preloaded CertifiedKey, with a fallback to the first/only cert when SNI is absent or unmatched — that keeps every existing single-cert program byte-for-byte compatible (backward compat is non-negotiable here).
2. Accept on a tokio::net::TcpListener, wrap each stream with tokio_rustls::TlsAcceptor, and feed it to warp::service(routes) through hyper::server::conn::Http::serve_connection. warp::service() exists precisely for this, so the routing/respond machinery is untouched.
3. validate_tls_pem_files already parses and validates PEM chains — reuse it per entry so we keep the actionable up-front error messages instead of an opaque bind failure.

Surface syntax. Of the three options in the issue, the cert-map form reads best and is purely additive:

store certs as map with
    "wfl.fyi" as map with "certificate" as "fyi.pem" and "key" as "fyi.key"
    "webfirstlanguage.com" as map with "certificate" as "old.pem" and "key" as "old.key"
listen on port 443 secured with certificates certs as web_server

secured with certificate ... and key ... stays exactly as-is and simply becomes the one-entry case internally. Worth noting for the motivating deployment: the redirect listener form is HTTP-only, so serving a 301 for the retired domain over HTTPS needs a valid cert for that name — which is exactly what this unlocks.

Next steps I'd want before implementing: a decision from you on the surface syntax (cert-map vs. resolver-behind-existing-syntax), since that's the only part that's a language change rather than an internals change. Tests should cover: single-cert programs unchanged (regression), SNI hit, SNI miss → fallback cert, and a bad entry in the map producing the same actionable PEM error we give today.

Suggested labels: enhancement, web-server, tls.

Posted by the WFL repo warden (automated triage pass).

[logbie]

Update from this pass — this issue is now also the fix for an open high-severity security alert.

My assessment above recommended terminating TLS ourselves (rustls::ServerConfig + with_cert_resolver + tokio_rustls::TlsAcceptor + warp::service(routes)) rather than staying inside warp::serve().tls(). That refactor turns out to be load-bearing for more than SNI.

warp 0.3.7 (features = ["tls"]) → tokio-rustls 0.25 → rustls 0.22.4 → rustls-webpki 0.102.8, which is Dependabot alert #49 (high): DoS via panic on malformed CRL BIT STRING, open since 2026-04-24. It cannot be patched in place — 0.102.8 and rustls 0.22.4 are the last releases of their respective lines, so there is no in-line fix, and cargo update cannot cross the semver boundary while warp pins tokio-rustls ^0.25. (This is also why the Dependabot Updates workflow has failed on every rescan since June.)

Building the ServerConfig ourselves against rustls 0.23 — which is already in Cargo.lock via sqlx, carrying the patched rustls-webpki 0.103.13 — drops the vulnerable chain from the dependency graph entirely. One refactor closes both this issue and the high-severity alert. Full analysis in #610.

That materially raises the priority of this issue from "post-production-readiness enhancement" to "the vehicle for a security fix." The fix shape and the single-cert backward-compat regression test are unchanged from my assessment above.

Posted by the WFL repo warden (automated triage pass).

_{(This comment previously contained a duplicate of the 2026-07-11 assessment, posted in error by the warden tooling; corrected in place.)}

[logbie]

Superseding update — corrected security disposition (supersedes my earlier update that framed #600 as the fix vehicle for a reachable High).

A source-level reachability re-review (during the #610 Phase-1 audit, PR #614) shows that framing overreached — it treated the presence of rustls-webpki in the dependency graph as WFL exploitability. It isn't:

• Dependabot alert Fix Linux smoke test to find DEB file in correct location #49 (GHSA-82j2-j2ch-gfr8) panics only with opt-in RevocationOptions + attacker-controlled CRL bytes; the advisory explicitly states default rustls configurations are unaffected.
• WFL's only TLS setup is warp::serve(routes).tls().cert_path(…).key_path(…) (src/interpreter/mod.rs:6441). warp 0.3.7 defaults client auth to TlsClientAuth::Off / with_no_client_auth(), and WFL configures no CRL / RevocationOptions anywhere (verified by grep across src/ and crates/). The vulnerable revocation-checking path is therefore never reached.

Corrected disposition: alert #49 = "vulnerable code not used" (should be recorded/dismissed as such on the Security tab). #600 is not a reachable High WFL security defect, and its TLS rewrite is not established as the required remediation for that alert. The chain being present in the lockfile does not, by itself, make it exploitable here.

Scope of #600 going forward (kept separate): #600 is the SNI / multiple-certificates on one :443 enhancement — a multi-tenant deployment ergonomics feature, prioritized as post-production-readiness, independent of the (non-reachable) security alert.

Full audit trail: the #614 inventory + containment diaries, the regression-index header, and PR metadata have all been updated to this disposition; a matching correction is posted on the #610 tracker.

---

Generated by Claude Code