[bitnami/influxdb] v2: Serverside TLS doesn't work

[D1StrX]

While this is the correct configuration, at initial setup I get the error below.

  configuration: |-
    tls-cert: /path/to/cert.crt
    tls-key: /path/to/privatekey.key

I'm using a simple let's encrypt cert-manager secret and mounting that into the pod. Also including this;

  extraTls:
    - hosts:
        - influx.domain.tld
        - <svc>.<namespace>.svc.cluster.local
      secretName: influx-cert-secret

influxdb 19:09:54.08 INFO  ==>
influxdb 19:09:54.08 INFO  ==> Welcome to the Bitnami influxdb container
influxdb 19:09:54.09 INFO  ==> Subscribe to project updates by watching https://github.com/bitnami/containers
influxdb 19:09:54.09 INFO  ==> Submit issues and feature requests at https://github.com/bitnami/containers/issues
influxdb 19:09:54.09 INFO  ==> Upgrade to Tanzu Application Catalog for production environments to access custom-configured and pre-packaged software components. Gain enhanced features, including Software Bill of Materials (SBOM), CVE scan result reports, and VEX documents. To learn more, visit https://bitnami.com/enterprise
influxdb 19:09:54.09 INFO  ==>
influxdb 19:09:54.09 INFO  ==> ** Starting InfluxDB setup **
influxdb 19:09:54.19 DEBUG ==> Validating settings in INFLUXDB_* env vars...
influxdb 19:09:54.19 INFO  ==> Custom configuration /opt/bitnami/influxdb/etc/config.yaml detected!
influxdb 19:09:54.19 WARN  ==> The 'INFLUXDB_' environment variables override the equivalent options in the configuration file.
influxdb 19:09:54.19 WARN  ==> If a configuration option is not specified in either the configuration file or in an environment variable, InfluxDB uses its internal default configuration
influxdb 19:09:54.20 INFO  ==> Starting InfluxDB in background...
ts=2024-10-23T19:09:54.889487Z lvl=info msg="Welcome to InfluxDB" log_id=0sQhP~IG000 version=v2.7.10 commit=f302d97 build_date=2024-10-23T19:09:54Z log_level=info
ts=2024-10-23T19:09:54.890160Z lvl=info msg="Resources opened" log_id=0sQhP~IG000 service=bolt path=/bitnami/influxdb/influxd.bolt
ts=2024-10-23T19:09:54.890200Z lvl=info msg="Resources opened" log_id=0sQhP~IG000 service=sqlite path=/bitnami/influxdb/influxd.sqlite
ts=2024-10-23T19:09:54.891942Z lvl=info msg="Using data dir" log_id=0sQhP~IG000 service=storage-engine service=store path=/bitnami/influxdb/data
ts=2024-10-23T19:09:54.891960Z lvl=info msg="Compaction settings" log_id=0sQhP~IG000 service=storage-engine service=store max_concurrent_compactions=4 throughput_bytes_per_second=50331648 throughput_bytes_per_second_burst=50331648
ts=2024-10-23T19:09:54.891965Z lvl=info msg="Open store (start)" log_id=0sQhP~IG000 service=storage-engine service=store op_name=tsdb_open op_event=start
ts=2024-10-23T19:09:54.891994Z lvl=info msg="Open store (end)" log_id=0sQhP~IG000 service=storage-engine service=store op_name=tsdb_open op_event=end op_elapsed=0.029ms
ts=2024-10-23T19:09:54.892015Z lvl=info msg="Starting retention policy enforcement service" log_id=0sQhP~IG000 service=retention check_interval=30m
ts=2024-10-23T19:09:54.892026Z lvl=info msg="Starting precreation service" log_id=0sQhP~IG000 service=shard-precreation check_interval=10m advance_period=30m
ts=2024-10-23T19:09:54.892403Z lvl=info msg="Starting query controller" log_id=0sQhP~IG000 service=storage-reads concurrency_quota=1024 initial_memory_bytes_quota_per_query=9223372036854775807 memory_bytes_quota_per_query=9223372036854775807 max_memory_bytes=0 queue_size=1024
ts=2024-10-23T19:09:54.894013Z lvl=info msg="Configuring InfluxQL statement executor (zeros indicate unlimited)." log_id=0sQhP~IG000 max_select_point=0 max_select_series=0 max_select_buckets=0
ts=2024-10-23T19:09:54.896436Z lvl=info msg=Starting log_id=0sQhP~IG000 service=telemetry interval=8h
ts=2024-10-23T19:09:54.896715Z lvl=info msg=Listening log_id=0sQhP~IG000 service=tcp-listener transport=https addr=0.0.0.0:8086 port=8086
ts=2024-10-23T19:09:55.290473Z lvl=info msg="http: TLS handshake error from 127.0.0.1:59526: EOF" log_id=0sQhP~IG000 service=http
influxdb 19:09:55.29 INFO  ==> Deploying InfluxDB from scratch
influxdb 19:09:55.29 INFO  ==> Creating primary setup...
Error: failed to check if already set up: 400 Bad Request
influxdb 19:09:55.38 INFO  ==> Stopping InfluxDB...

When I run the setup without TLS configuration, it works and I can connect over https to InfluxDB due to the TLS offloading on ingress.
When I start it a second time, with TLS enabled again, it gets stuck at pods 0/1 and restarting:
Liveness probe failed: HTTP probe failed with statuscode: 400
Error: 400 Bad Request: unable to decode response content type ""

ts=2024-10-23T19:23:10.499412Z lvl=info msg="Configuring InfluxQL statement executor (zeros indicate unlimited)." log_id=0sQiAYkW000 max_select_point=0 max_select_series=0 max_select_buckets=0
ts=2024-10-23T19:23:10.594860Z lvl=info msg=Listening log_id=0sQiAYkW000 service=tcp-listener transport=https addr=0.0.0.0:8086 port=8086
ts=2024-10-23T19:23:10.595038Z lvl=info msg=Starting log_id=0sQiAYkW000 service=telemetry interval=8h

Setting url: https://localhost:8086 is also not fixing the issue:

  configuration: |-
    tls-cert: /path/to/cert.crt
    tls-key: /path/to/privatekey.key
    url: "https://localhots:8086"

Ref: https://community.influxdata.com/t/influx-command-does-not-work-with-tls-enabled/28758/2

Originally posted by @D1StrX in #30003 (comment)

[D1StrX]

I think https://localhots:8086 isn't going to work, since the certificate doesn't/cannot contain that SAN. But neither is https://<svc>.<namespace>.svc.cluster.local:8086

[dgomezleon]

Hi @D1StrX ,

Sorry for the delay.

ts=2024-10-23T19:09:55.290473Z lvl=info msg="http: TLS handshake error from 127.0.0.1:59526: EOF" log_id=0sQhP~IG000 service=http
influxdb 19:09:55.29 INFO ==> Deploying InfluxDB from scratch
influxdb 19:09:55.29 INFO ==> Creating primary setup...
Error: failed to check if already set up: 400 Bad Request
influxdb 19:09:55.38 INFO ==> Stopping InfluxDB...

Could you try including "localhost" and "127.0.0.1" in the SAN? Maybe the probes are failing because you're missing that hostname and therefore the client can't verify the certificates.

[D1StrX]

That's not allowed in a let's encrypt certificate.

[dgomezleon]

I see

Have you tried in this case to disable the livenessProbe? In that case you could use a custom one to verify the right behavior.