How to connect Jaeger v2 to OpenSearch with self-signed certificates?

[CptOrange16]

Hi everyone! 👋I'm trying to deploy Jaeger v2 (Helm chart 4.4.7, app version 2.12.0) with OpenSearch storage, but I'm hitting TLS certificate verification errors and can't find a working configuration.

The problem

OpenSearch is running with a self-signed certificate that's valid for node-0.example.com and localhost, but not for the Kubernetes service name opensearch-cluster-master.

When Jaeger tries to connect, it fails with:
failed to initialize storage 'primary_store': failed to create Elasticsearch client: health check timeout: Head "https://opensearch-cluster-master:9200": tls: failed to verify certificate: x509: certificate is valid for node-0.example.com, localhost, not opensearch-cluster-master: no Elasticsearch node available

What I've Tried

1. Adding TLS skip verification in userconfig:

jaeger_storage:
  backends:
    primary_store:
      opensearch:
        server_urls: ["https://opensearch-cluster-master:9200"]
        auth:
          basic:
            username: "admin"
            password: "password"
        tls:
          insecure: true
          insecure_skip_verify: true

Result: The tls block appears to be ignored - same error occurs.

I created my configuration based on the values provided here https://github.com/jaegertracing/jaeger/blob/main/cmd/jaeger/config-opensearch.yaml

Full Jaeger Configuration (click to expand)

jaeger:
  fullnameOverride: jaeger
  jaeger:
    image:
      repository: jaeger
      tag: 0.0.3
      pullPolicy: Never
    extraEnv:
      - name: METRICS_BACKEND
        value: "prometheus"
      - name: PROMETHEUS_SERVER_URL
        value: "http://prometheus-server:9090"
      - name: PROMETHEUS_QUERY_NORMALIZE_CALLS
        value: "true"
      - name: PROMETHEUS_QUERY_NORMALIZE_DURATION
        value: "true"
      - name: QUERY_BASE_PATH
        value: "/jaeger/ui"
    resources:
      limits:
        memory: 400Mi
  userconfig:
    service:
      extensions: [jaeger_storage, jaeger_query, healthcheckv2]
      pipelines:
        traces:
          receivers: [otlp]
          processors: [batch]
          exporters: [jaeger_storage_exporter]
      telemetry:
        resource:
          service.name: jaeger
        metrics:
          level: detailed
          readers:
            - pull:
                exporter:
                  prometheus:
                    host: 0.0.0.0
                    port: 8888
    extensions:
      healthcheckv2:
        use_v2: true
        http:
          endpoint: 0.0.0.0:13133
      jaeger_query:
        base_path: /jaeger
        storage:
          traces: primary_store
        ui:
          config_file: /etc/jaeger/ui-config.json
      jaeger_storage:
        backends:
          primary_store:
            opensearch:
              server_urls: ["https://opensearch-cluster-master:9200"]
              auth:
                basic:
                  username: "admin"
                  password: "password"
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
          http:
            endpoint: 0.0.0.0:4318
    processors:
      batch:
    exporters:
      jaeger_storage_exporter:
        trace_storage: primary_store

2. Using the ClusterIP directly:

Result: Error changes to show certificate is valid for ::1, 127.0.0.1 but not the ClusterIP.

3. Using HTTP:

Result: Connection refused (OpenSearch requires HTTPS).

Related Issues
I found several related issues:

• [Bug]: Missing support for extraSecretMounts helm-charts#735 - Missing extraSecretMounts support (opened Feb 2026, still open)
• [Jaeger & Jaeger Operator] Cannot skip SSL verify for existing Elasticsearch  helm-charts#348 - TLS skip verification not working in v1 (closed as "not planned" in 2022)
• Various issues from 2019-2021 reporting similar problems

My Questions

1. Is there a working way to skip TLS verification in Jaeger v2's jaeger_storage extension? If yes, what's the correct configuration?
2. Can I provide a custom CA certificate? I can extract the OpenSearch CA cert, but I don't see how to mount it or configure Jaeger to use it.
3. What's the recommended approach for connecting Jaeger v2 to OpenSearch/Elasticsearch with self-signed certificates in Kubernetes?
4. Should I use Jaeger v1 instead? Given that v1 is EOL but seems to have better TLS options, and v2 appears to be missing this functionality - what's the migration path?

Why This Matters

Internal Kubernetes clusters commonly use self-signed certificates for services like OpenSearch/Elasticsearch. If Jaeger v2 doesn't support either:

• Skipping TLS verification, or
• Providing custom CA certificates
  ...then it's unusable in these very common environments. This creates a significant blocker for migrating from v1 to v2.

Is this functionality planned?

What's the expected timeline?

Should I deploy Jaeger v1 (even though EOL) as a temporary solution?

Any guidance would be really appreciated!

[dosubot[bot]]

Hi @CptOrange16! I'm Dosu and I’m helping the jaeger team.

I see a potential issue with your configuration. In Jaeger v2, the correct TLS field is insecure: true (not insecure_skip_verify). Looking at the TLS handling code, when insecure: true is set, it properly configures InsecureSkipVerify: true in the Go TLS config.

Try this configuration:

jaeger_storage:
  backends:
    primary_store:
      opensearch:
        server_urls: ["https://opensearch-cluster-master:9200"]
        tls:
          insecure: true  # This is the correct field name
        auth:
          basic:
            username: "admin"
            password: "password"

Note: Remove insecure_skip_verify - it's not a valid field in Jaeger v2's OpenTelemetry-based TLS configuration.

For production with CA certificates, the better approach is:

tls:
  insecure: false
  ca_file: /path/to/ca-cert.pem

You'll need to mount your OpenSearch CA certificate into the Jaeger pod and reference the path. The Helm chart's lack of extraSecretMounts support (issue #735) does make this harder, but you can work around it with:

• Custom extraVolumes and extraVolumeMounts if your chart version supports them
• A ConfigMap or Secret mounted at a known path

One more thing to check: There's a known issue where insecure: true didn't work for some users in earlier v2 releases. If the corrected field name still doesn't work, enable debug logging with telemetry.logs.level: debug to see if there are configuration parsing errors preventing the TLS settings from being applied.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}