Support mounting TLS certificates for inputs without enabling HTTP TLS / bypassing SAN check

[radimk]

Is your feature request related to a problem? Please describe.

I'm running Graylog 7.0 on Kubernetes (EKS) and need to expose a GELF TCP input with TLS for applications running outside the cluster. The external clients connect through a load balancer (AWS CLB) and currently I have to run a separate nginx stream proxy that terminates TLS and forwards plain TCP to Graylog. This proxy introduces message loss: it buffers data between two independent TCP connections, and when the client closes the connection, the proxy may discard buffered data before forwarding it upstream to Graylog.

The obvious solution is to configure TLS directly on the Graylog GELF TCP input (which Graylog supports natively). The Helm chart has a graylog.config.tls section that mounts a Kubernetes TLS secret into the pod at /usr/share/graylog/tls/. However, enabling this feature also:

• Enables HTTPS on the HTTP interface (GRAYLOG_HTTP_ENABLE_TLS=true), which changes internal cluster communication and requires ingress reconfiguration.
• Requires the certificate SAN to include *.{service-name}.{namespace}.svc.cluster.local — the init container validates this and exits with error if it doesn't match. Certificates issued by Let's Encrypt (or any public CA) cannot include .local domains, making this check impossible to satisfy with publicly-trusted certificates.

The result is that there's no supported way to mount a publicly-trusted TLS certificate into the Graylog pod for use by a GELF/Syslog input without also enabling HTTPS on the web interface and satisfying the internal SAN requirement.

Describe the solution you'd like

Separate the certificate mount from the HTTP TLS feature. Add a Helm values section (e.g. graylog.extraVolumes / graylog.extraVolumeMounts, or a dedicated graylog.inputs[].tls block) that allows mounting TLS secrets for input use without enabling GRAYLOG_HTTP_ENABLE_TLS.

Make the SAN check optional or scoped. The init container's openssl x509 -checkhost validation assumes the mounted certificate is for internal cluster communication. When the certificate is intended for external-facing inputs (GELF TCP, Syslog TCP), the internal FQDN SAN is irrelevant. Consider:

• A values flag to skip the SAN check (e.g. graylog.config.tls.validateSAN: false)
• OR only run the check when GRAYLOG_HTTP_ENABLE_TLS is actually true
• OR allow multiple TLS secrets (one for HTTP with internal SAN, one for inputs with public SAN)

Describe alternatives you've considered

• Running a separate TLS-terminating proxy (nginx stream): Works but introduces a store-and-forward hop that causes message loss on connection close (proxy discards buffered data when client sends RST/FIN before proxy finishes forwarding).
• Overriding GRAYLOG_HTTP_ENABLE_TLS via env var while keeping tls.enabled: true: The certificate is mounted but the init container still fails the SAN check and exits before the main container starts.
• Using Graylog's internal/self-signed certificates for the input: External clients won't trust the certificate without custom CA configuration, which requires modifying all client applications.
• Overriding the init-script ConfigMap: Fragile; breaks on chart upgrades.

Additional context

• Chart version: graylog/graylog v1.0.0 (appVersion 7.0)
• The relevant init container logic is in charts/graylog/templates/config/init-graylog.yaml line 18
• Use case: GELF TCP + TLS input open for application outside of cluster, certificate issued by Let's Encrypt via cert-manager
• The chart also lacks extraVolumes/extraVolumeMounts support which would be an alternative escape hatch (the older community chart at helm/charts/stable/graylog had this)