diff --git a/modules/manage/pages/kubernetes/security/tls/k-cert-manager.adoc b/modules/manage/pages/kubernetes/security/tls/k-cert-manager.adoc
index 625833dc99..469d8e18c5 100644
--- a/modules/manage/pages/kubernetes/security/tls/k-cert-manager.adoc
+++ b/modules/manage/pages/kubernetes/security/tls/k-cert-manager.adoc
@@ -303,6 +303,23 @@ helm upgrade --install redpanda redpanda/redpanda --namespace <namespace> --crea
 ====
 include::manage:partial$kubernetes/tls-update-note.adoc[]
 ====
++
+When you provide your own Issuer, the Helm chart does not add the brokers' internal Kubernetes Service addresses to the Certificate, because public CAs such as Let's Encrypt cannot issue certificates for cluster-local names. If your Issuer is a private CA that can issue certificates for internal addresses, set `applyInternalDNSNames` to `true`. This setting adds the internal addresses to the Certificate so that clients inside the Kubernetes cluster can validate connections to the internal listeners with the same Certificate.
++
+Because a private CA is not publicly trusted, also set `caEnabled` to `true`. The chart then uses the `ca.crt` file in the Certificate's Secret for the listener trust stores and for chart-managed clients such as `rpk`. When `caEnabled` is `false`, listeners fall back to the container's CA certificates, which do not trust your private CA.
++
+[,yaml]
+----
+tls:
+  enabled: true
+  certs:
+    external:
+      issuerRef:
+        name: <issuer-name>
+        kind: <issuer>
+      applyInternalDNSNames: true
+      caEnabled: true
+----
 
 . Make sure the Certificates are in a `READY` state.
 +