Manual mTLS Certificate Update Gets Overwritten Due to Missing ConfigMap Update

[Sridhar-Siddureddy]

---

Issue

While following the [official Dapr documentation](https://docs.dapr.io/operations/security/mtls/#custom-certificates-bring-your-own) for configuring custom mTLS certificates, there are three methods listed:

1. Using the Dapr CLI
2. Using the Helm upgrade
3. Manually updating the dapr-trust-bundle secret

Currently, both the Dapr CLI and Helm methods fail under certain conditions:

Dapr CLI issue:

If the Dapr control plane was installed via Azure CLI (az aks enable-addons --addons dapr --name <cluster-name> --resource-group <resource-group>), it installs a chart version such as 1.15.3-msft.2 which is not available in the official [Dapr Helm chart repo](https://dapr.github.io/helm-charts). Running the CLI renewal fails with:

certificate rotation failed: chart "dapr" version "1.15.3-msft.2" not found in https://dapr.github.io/helm-charts repository

Helm upgrade issue:

Attempting to use helm upgrade fails due to mismatched properties between the Microsoft-specific chart version and the public Dapr chart repo. The values.yaml structure and expected parameters differ, resulting in errors during upgrade (e.g., unknown fields, incompatible chart values, etc.).

Due to these issues, the only viable method is manual secret update. But even this has a caveat...

Secret rollback issue:

After manually updating the dapr-trust-bundle Secret with custom certificates (issuer.crt, issuer.key, ca.crt), the changes are automatically reverted shortly after. This behavior occurs because the Dapr Helm chart also provisions a dapr-trust-bundle ConfigMap, which contains the root certificate (ca.crt) and is referenced by the Sentry deployment.

If the ConfigMap is not updated to match the new certificate values, it causes the system to regenerate and reapply the original Secret values - effectively overriding any manual updates.

This behavior is defined in the Dapr Helm chart template used for deploying Dapr Sentry:
🔗 dapr_sentry_deployment.yaml

---

URL of the docs

• https://docs.dapr.io/operations/security/mtls/#custom-certificates-bring-your-own
• https://learn.microsoft.com/en-us/azure/aks/dapr-settings?tabs=cli#generate-a-new-dapr-generated-self-signed-certificate
• https://learn.microsoft.com/en-us/azure/aks/dapr-settings?tabs=cli#manage-your-own-user-supplied-x509-certificates

---

Expected content

The documentation should clearly state that:

• If using the manual update method, you must first update the dapr-trust-bundle ConfigMap, followed by the Secret. Otherwise, the custom values will be overwritten.
• The Dapr CLI may not work if the installed version is Microsoft-specific (*-msft.*) and doesn't exist in the official Helm repo.
• The Helm upgrade path fails due to mismatch in chart structure and parameters between the Microsoft-maintained and official Dapr Helm charts.

---

Screenshots

• CLI Failure:
  

• Helm chart version mismatch:
  

---

Additional context

A related issue was also raised here:
🔗 Azure AKS Docs GitHub Issue

The current workaround is:

1. First update the dapr-trust-bundle ConfigMap with the new ca.crt value.
2. Then update the Secret with the base64-encoded versions of the custom issuer.crt, issuer.key, and ca.crt.

This critical step of updating the ConfigMap is not currently documented in the official Dapr guide and should be added to prevent confusion and failed manual certificate setups.

---

[yaron2]

Thanks, would you be willing to open a PR with the required info?