[bitnami/elasticsearch] with autoGenerated:true yields incorrect certificate for elasticsearch service.

[ryders]

Name and Version

bitnami/elasticsearch-21.4.2

What architecture are you using?

amd64

What steps will reproduce the bug?

When installing with bitnami/elasticsearch using helm with security.tls.autoGenerated:true (see values.yaml), rollout is successful and everything seems to work fine.

However when connecting to the elastic search using ..svc.cluster.local (or just the less qualified, as elasticsearch) the certificate returned is NOT signed for CN: elasticsearch but instead signed using CN: elasticsearch-coordinating, and Alternate Names: elasticsearch (amongst others).

Given that by default, OpenSSL::SSL.verify_certificate_identity checks the common name (CN) field in the certificate... not the SAN... using OpenSSL::SSL::VERIFY_PEER seems impossible to configure?

Are you using any custom parameters or values?

helm upgrade --install elasticsearch oci://registry-1.docker.io/bitnamicharts/elasticsearch --create-namespace -n test-ns --values values.yaml

with the following:

# values.yaml
security:
  enabled: true
  elasticPassword: "whateveryourfeellikeman"
  tls:
    autoGenerated: true

What is the expected behavior?

I would expect that connecting to elasticsearch directly, using OpenSSL:SSL:VERIFY_PEER and the correct ca_file would function.

I understand bitnami/redis, bitnami/postgres and others are not exactly following the same layer topology / k8s components, but they do work with VERIFY_PEER

What do you see instead?

certificate returned by connecting to elasticsearch, clearly showing CN as elasticsearch-coordinating:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            9e:57:81:52:0b:ad:97:f1:f5:90:85:eb:53:d2:d5:e6
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=elasticsearch-ca
        Validity
            Not Before: Jan 19 12:37:36 2025 GMT
            Not After : Jan 19 12:37:36 2026 GMT
        Subject: CN=elasticsearch-coordinating
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b9:f8:d4:f0:92:4e:27:7f:29:47:1f:e0:81:a7:
                    51:03:99:c8:30:0d:c0:db:e4:3a:13:4f:75:78:cb:
                    53:d1:ec:71:e6:b6:37:16:5e:49:77:8c:06:44:41:
                    08:df:5e:c5:a9:4c:16:c5:9f:ae:ec:69:a8:1f:e2:
                    fc:eb:4a:88:92:78:63:39:af:18:b3:1d:e3:b1:e7:
                    84:f3:ae:0d:d9:6a:40:ec:27:55:66:e7:95:44:fe:
                    68:1b:08:b5:09:b4:da:7e:40:69:4c:93:bb:28:aa:
                    20:91:a8:f0:a2:6f:72:12:62:e8:39:4b:97:b0:77:
                    ea:e3:b5:c6:ea:51:b6:72:97:da:af:c5:73:1c:31:
                    8b:3b:c0:f4:a3:77:24:40:8a:96:4b:66:c7:c1:46:
                    ae:a9:26:e4:05:6b:c6:d0:31:24:21:43:48:2d:75:
                    d9:e8:31:6c:09:24:59:3c:a5:78:15:1c:c9:e3:6b:
                    42:c2:e2:d1:9d:4a:d8:ca:c2:02:6f:e9:03:88:78:
                    a3:97:40:8d:84:04:94:ae:0d:4e:2e:02:91:1a:9b:
                    d3:5e:2e:4d:84:59:6f:f3:0d:3a:68:1f:09:31:2d:
                    25:08:ec:b5:58:c8:45:22:ea:27:b9:41:50:0d:d4:
                    3e:ce:5d:d1:52:34:6b:b9:fb:75:51:2d:1d:68:ea:
                    fe:11
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier: 
                41:D3:3E:D4:FF:28:9A:DC:4A:35:64:CD:A7:54:9A:79:DA:CD:A9:83
            X509v3 Subject Alternative Name: 
                DNS:elasticsearch, DNS:elasticsearch.test-ns.svc.cluster.local, DNS:*.elasticsearch-coordinating-hl.test-ns.svc.cluster.local, DNS:elasticsearch-coordinating-hl.test-ns.svc.cluster.local, DNS:elasticsearch-coordinating, DNS:127.0.0.1, DNS:localhost
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        7a:92:7e:5f:96:a2:02:46:3d:68:fc:7a:89:6c:34:05:97:d3:
        63:dd:8a:e2:70:08:29:f3:75:11:6d:d2:94:8c:09:8f:72:d7:
        8d:e2:fb:53:64:19:b7:ea:ce:2b:11:bf:97:8f:7a:4c:f1:f3:
        60:34:5c:2a:0a:1c:6b:b4:4f:2b:36:5c:75:41:18:a9:01:85:
        23:16:df:22:71:3b:5b:18:c1:7d:41:7b:de:71:16:11:18:9f:
        76:e5:8d:ef:b4:11:42:38:f5:5c:bd:3b:2c:87:6c:03:60:12:
        59:36:68:51:a2:43:55:d6:8a:de:ad:73:45:f7:cc:32:1b:0f:
        a8:9d:3d:c2:29:e2:ae:7d:87:c1:9b:2a:c4:ac:2f:6a:16:02:
        b9:bc:d5:31:8a:f7:8f:98:da:6c:b5:32:57:85:8c:c1:e6:ee:
        01:ff:86:ee:6a:9f:39:dd:c7:87:5f:1d:7d:30:45:20:8d:eb:
        9d:85:86:2f:f1:40:23:61:f1:15:b3:28:e2:01:fe:c1:0f:3c:
        25:22:cd:15:b6:01:a0:04:7e:12:3d:da:59:4b:26:02:a1:aa:
        78:03:e6:bc:a5:2f:2f:92:7e:f7:0a:cd:6b:c4:d3:a7:15:f5:
        c7:9f:d4:f7:2e:57:17:d9:dd:8f:a2:cd:d4:8f:1c:5a:c9:96:
        de:0e:29:77

Additional information

I understand a quick (and dirty) approach is to use VERIFY_NONE, however I'm not a fan of cutting corners when corners needn't be cut.

Connecting to elasticsearch-coordinating-hl service would yield the same problem (CN: elasticsearch-coordinating).

I created my own certificates but that seemed problematic when spinning off the chart resulting in SSL/TLS request received but SSL/TLS is not enabled on this node, got (16,3,1,7),, hence being unsuccessful 😭

Any additional information or guidance towards achieving VERIFY_PEER would be great, I'd sure consider contributing some additional documentation once I have this to work!

... unless I'm missing something here?!

[javsalgar]

Hi!

Thank you so much for reporting. So, if I understand correctly, you would like to allow the chart allow overriding the autogenerated certificate CN with a custom value, is that correct?