JHipster Kubernetes Ingress TLS Hosts Configuration for Service FQDN Validation

Goal: Ensure that internal service calls made from a JHipster application running in Kubernetes pass hostname validation when Istio enforces mutual TLS.

Uncertainty: The JHipster generator creates an Ingress TLS block that omits the explicit hosts field, relying on wildcard defaults. This leaves it unclear whether the service’s fully qualified domain name (e.g., api.myapp.svc.cluster.local) should be automatically added to the TLS hosts list to match the certificate’s SANs, or whether users must rely on external tools such as cert‑manager to manage SANs.

Questions: Should JHipster automatically inject the service’s FQDN into the Ingress TLS hosts list? What are the risks of omitting the hosts entry for certificate validation in strict mTLS environments? How can users verify alignment between the Ingress TLS hosts and the certificate SANs without manual intervention?