Remote error tls bad certificate

[sashalarsoo]

Component(s)

collector

What happened?

Hey
Im using these params for operator because i dont want to use cert manager:
admissionWebhooks:
certManager:
enabled: false
autoGenerateCert:
enabled: true
recreate: true

But after a few hours/days i have got everywhere 2026/05/26 15:45:00 http: TLS handshake error from 10.244.1.0:41726: remote error: tls: bad certificate

Kubernetes Version

1.35.0

Operator version

ghcr.io/open-telemetry/opentelemetry-operator/opentelemetry-operator:0.151.0

Collector version

docker.io/otel/opentelemetry-collector-contrib:0.152.0

Environment information

Environment

OS: (e.g., "Ubuntu 20.04")
Compiler(if manually compiled): (e.g., "go 14.2")

Log output

Additional context

No response

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[frzifus]

Looking at the config, it seems that are helm settings?

Qwen3.6

The admissionWebhooks.autoGenerateCert and recreate options are features of the Helm chart, which lives in the opentelemetry-helm-charts repository. The operator itself doesn't contain any auto-certificate generation or webhook configuration reconciliation logic — it relies entirely on externally provided certs mounted into the pod.

With recreate: true, every helm upgrade generates new self-signed certificates. If the pod doesn't restart after an upgrade (controlled by manager.rolling in the Helm values), it continues serving the old certificate while the webhook configuration already has the new caBundle — causing the tls: bad certificate error.

A few things to check:

• Is manager.rolling enabled in your Helm values? If not, the pod won't automatically restart on upgrades to pick up the new certs.
• Are you using a GitOps tool (ArgoCD, Flux) that might be reconciling and modifying the webhook configurations?
• Can you verify whether the caBundle in your MutatingWebhookConfiguration / ValidatingWebhookConfiguration matches the CA in the mounted secret (ca.crt in the *-service-cert Secret)?

[sashalarsoo]

These are helm values yes.
Are you using a GitOps tool (ArgoCD, Flux) that might be reconciling and modifying the webhook configurations?

Yes with autosync

Is manager.rolling enabled in your Helm values? If not, the pod won't automatically restart on upgrades to pick up the new certs.
No i will try to add this param

[sashalarsoo]

I just want a stable operator that allows me to inject instrumentation without cert manager.

[sashalarsoo]

Still having the error even with rolling enabled.