Modern TLS, with nothing extra to configure unless you want a private ACME server.
HTTPS listeners negotiate h2 automatically via ALPN: h2 offered first, falling back to http/1.1 on the same listener for clients that don't support it. Nothing to configure, and not feature-gated: hyper already ships the h2 builder. The proxy-to-upstream leg is always HTTP/1.1 regardless of what the client negotiated. Forwarding the client's HTTP version through to an http/1.1-only upstream client doesn't work, which is exactly the bug torana's own h2 integration test caught during development.
Build with cargo build --release --features acme (off by default; adds ~1.6 MB via rustls-acme, which carries its own rustls stack internally). listener.acme replaces a static tls_cert/tls_key pair; certificates are obtained and renewed automatically via RFC 8555 using the TLS-ALPN-01 challenge, no separate port 80 listener needed. Not combinable with tls_client_ca (mTLS) on the same listener yet.
[[listener]] addr = "0.0.0.0:443" protocol = "https" [listener.acme] domains = ["example.com"] contact_emails = ["admin@example.com"] cache_dir = "./acme-cache" # staging = true # use Let's Encrypt's staging directory while testing
directory_url targets a private ACME server instead of Let's Encrypt, and ca_cert trusts that server's CA if it isn't in the public web PKI, exactly how torana's own end-to-end test verifies against a local Pebble instance (Let's Encrypt's own ACME protocol test server) rather than a mock. That test proves a genuine RFC 8555 issuance occurred by checking the served certificate's chain against Pebble's real issuing root, with a negative control confirming the same request fails TLS verification without that trust anchor; see scripts/test-acme-e2e.sh and torana/tests/acme_e2e.rs in the repo.