When Elasticseach auto configs security, is there any way to inject SANs of my own choosing into the http_ca.crt?

Hello, I am running Elasticsearch in Kubernetes, and everything is up and running well, but if I make any connections from other applications internally across Kubernetes to the exposed service on 9200, it fails the "hostname" check against the http_ca.crt. The security autoconfig adds the Kubernetes Pod NAME and IP into the SubjectAlternativeName field, but I am connecting to a kubernetes Service I created to expose port 9200 from the Elasticsearch pod. That service IP/name is not in the SAN in http_ca.crt. If I could get that in there, I think that would take care of the problem. Is there any way to control that?

I assume my only option is to NOT use Elastic autoconfig and manually do all the SSL configuration instead, maybe then I can control the SANs. It would be awesome if there was a setting that could predefine SANs before the autoconfig runs and just adds them for me.

Am I on the right track?

The SANs for the HTTP certificate are determine here:

We add:

  • All local IP addresses
  • localhost
  • The HOSTNAME environment variable
  • The values from network.publish_host (which defaults to network.host)
  • The values from http.publish_host (which defaults to http.host or network.publish_host)

It sounds like you want to set http.publish_host for your node, but there are a range of configuration options there (network.host, http.host, network.publish_host, http.publish_host) so you should check the docs and pick the right one for your needs.
Start here:

Also you say http_ca.crt but I don't think you really mean that.

The CA doesn't have hostnames because it's an issuer and doesn't belong to any particular host.
There is a separate HTTP cert on each node (signed by the http_ca) and my answer above assumes that you want the correct hostnames in that cert on each node.

You are right, it is not the http_ca.crt, but one of the others that gets generated into that certs directory, I did mis-state that.

That http.publish_host option sounds promising. I did find another workaround,
I used a "StatefulSet" in kubernetes to generate the Elasticsearch pod,
which causes the pod to always have the same name, even when it is killed and regenerated. So the fact that Elasticsearch ends up using the pod name as HOSTNAME, and hostname is put into the cert, that ends up working because that pod name/hostname remains constant. But I'm going to test the network.publish_host option as well, that may give me some more flexibility. Thank you for that.

I was able to create a standalone service in Kubernetes, expose ports 9200 and 9300 from my Elasticsearch pod, and then insert that Service name into the Elasticsearch HTTPs certificate using the http.publish_host setting. Thanks for the shove in the right direction.