Currently the HTTPS listener builds its rustls ServerConfig with .with_no_client_auth() hardcoded, so there is no way to require or verify a client certificate:
// lib/src/https.rs (~1483)
let mut server_config = RustlsServerConfig::builder_with_provider(provider.into())
.with_protocol_versions(&versions[..])
.map_err(|err| ListenerError::BuildRustls(err.to_string()))?
.with_no_client_auth() // <-- client auth is never possible
.with_cert_resolver(resolver);
Why this is standard, not a proxy-specific feature
Client certificate authentication is part of the TLS protocol itself, not an add-on borrowed from another reverse proxy:
- RFC 8446 (TLS 1.3), §4.3.2 — the server sends a CertificateRequest; the client answers with Certificate + CertificateVerify.
- RFC 5246 (TLS 1.2), §7.4.4 / §7.4.6 — the same CertificateRequest / client Certificate exchange.
rustls implements this natively through ServerConfig::builder().with_client_cert_verifier(...) and WebPkiClientVerifier. So this is about exposing a capability the protocol and the TLS stack already provide, which the worker currently disables.
Proposed shape (open to your preference)
A per-listener option on HttpsListenerConfig, e.g.:
- a client-auth mode: none (current default) / optional / required
- a set of trusted client CA certificates (PEM) the client cert must chain to
- optionally, CRLs for revocation
The mode maps directly onto rustls: required → WebPkiClientVerifier::builder(roots).build(), optional → .allow_unauthenticated(), none → the current with_no_client_auth(). Naming could follow rustls' own vocabulary rather than any specific proxy's.
Questions before any implementation
- Would you be open to this as a contributed PR?
- Do you have a preferred config surface — a new HttpsListenerConfig field, a dedicated request type, or something else?
- Any concern we should know about up front? (e.g. the mTLS session-resumption class of issues, or interaction with SNI-based cert selection / the shared listener model.)
Happy to prototype once the direction is agreed.
Currently the HTTPS listener builds its rustls ServerConfig with .with_no_client_auth() hardcoded, so there is no way to require or verify a client certificate:
Why this is standard, not a proxy-specific feature
Client certificate authentication is part of the TLS protocol itself, not an add-on borrowed from another reverse proxy:
rustls implements this natively through ServerConfig::builder().with_client_cert_verifier(...) and WebPkiClientVerifier. So this is about exposing a capability the protocol and the TLS stack already provide, which the worker currently disables.
Proposed shape (open to your preference)
A per-listener option on HttpsListenerConfig, e.g.:
The mode maps directly onto rustls: required → WebPkiClientVerifier::builder(roots).build(), optional → .allow_unauthenticated(), none → the current with_no_client_auth(). Naming could follow rustls' own vocabulary rather than any specific proxy's.
Questions before any implementation
Happy to prototype once the direction is agreed.