influxdb3 serve does not have support for specifying TLS options. At a minimum, I suggest being able to specify the private key and public certificate. InfluxDB 2.x OSS and 1.x Enterprise discusses this (2.x uses --tls-cert/--tls-key config/command line/env for this while 1.x uses https-certificate/https-private-key config options if you want to model it after a particular product).

Importantly, best practices indicate that the implementation needs to be able to support the private key being limited to reads by the user influxdb3 serve runs as (eg, in UNIX parlance, influxdb:influxdb ownership with 0600 permissions, root:influxdb ownership with 0640 permissions, etc (ie anything where other has no permissions). The private key should (of course) not be reachable via an API. I mention all of this in case there is a desire to store the certificate files in object store (which could possibly be made to work but it would be safer and simpler to support regular files).

While being able to specify the private key and the public certificate is the minimum requirement, being able to set the TLS minimum version (eg, via --tls-min-version or similar) as well as being able to specify the ciphers list is an often requested feature and it probably makes sense to implement them from the start. cc @gunnaraasen

I recommend using https://crates.io/crates/rustls since it has a compliant license, is widely used, we use it elsewhere and it puts us in a good position for FIPS certification down the line (see https://www.memorysafety.org/blog/rustls-with-aws-crypto-back-end-and-fips/ for some background). Conveniently, rustls also only supports TLS 1.2 and 1.3 and not earlier versions. These are both deemed safe in current practice (though we still should support --tls-min-version 1.3 (at least at some point)).