UMA certificate mismatch issue which prevents the auto-attach extension
Article ID: 436271
Updated On:
Products
Issue/Introduction
UMA unable to auto attach the java agent for an application
[ERROR] [I.AutoAttach.API.
Environment
DX O2
Cause
1.Issue Observed : The intermittent PKIX path validation failed: signature check failed error occurs when the podmonitor (client) and apm-probe-autoattach (server) hold different generations of TLS certificates in memory. Both load certificates once at startup and never reload from disk.
2.Trigger Scenario: The failure is triggered when the apm-probe-autoattach pod restarts after the TLS Secret has been updated with new certificates. The restarted server loads new certs, while daemonset pods still hold the old trust store in memory -- causing the signature mismatch.
3.Why the Reverse Does Not Fail: Restarting only the daemonset pods (without restarting apm-probe-autoattach) does not break auto-attach. The restarted podmonitor loads webhook-ca-cert.pem as its trust store -- a file written by apm-probe-autoattach at its own startup, consistent with the server's in-memory certificate.
4.Cluster Observation: Certificate differences detected on disk reflect Secret updates synced by the kubelet, but since neither the daemonset nor apm-probe-autoattach pods were restarted, both still hold the same original certificates in memory -- auto-attach works without errors
Resolution
WORKAROUNDS
1) Restart both the app-container daemonset on the worker node and apm-probe autoattach.
2) Delete the deployment and deploy the original deployment without our annotations. Delete all the annotations that is being added as part of UMA and the init containers.
SOLUTION
As part of Enhancement # DE661381 We are trying to find an efficient and multi-layered solution to the UMA certificate mismatch issue which prevents the auto-attach extension from communicating with the apm-probe-autoattach service.
Target release May 2026. For an update contact Broadcom Support
Additional Information
Feedback
