diff --git a/linkerd.io/content/2-edge/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2-edge/tasks/automatically-rotating-control-plane-tls-credentials.md
index 99f8dafbb9..2e356b0df8 100644
--- a/linkerd.io/content/2-edge/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2-edge/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -148,46 +148,6 @@ helm install \
   --wait
 ```
 
-Finally, we'll need to update cert-manager's RBAC permissions. By default
-cert-manager will only create certificate secrets in the namespace where it is
-installed. Linkerd, however, requires its identity issuer to be created in the
-`linkerd` namespace. To allow this, we create a `ServiceAccount` for
-cert-manager in the `linkerd` namespace with the required permissions.
-
-```bash
-kubectl apply -f - <<EOF
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: cert-manager
-  namespace: linkerd
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: Role
-metadata:
-  name: cert-manager-secret-creator
-  namespace: linkerd
-rules:
-  - apiGroups: [""]
-    resources: ["secrets"]
-    verbs: ["create", "get", "update", "patch"]
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: RoleBinding
-metadata:
-  name: cert-manager-secret-creator-binding
-  namespace: linkerd
-subjects:
-  - kind: ServiceAccount
-    name: cert-manager
-    namespace: linkerd
-roleRef:
-  kind: Role
-  name: cert-manager-secret-creator
-  apiGroup: rbac.authorization.k8s.io
-EOF
-```
-
 ### 3. Configure cert-manager to create the trust anchor
 
 As described in Buoyant's
@@ -609,11 +569,23 @@ another:
 
 ```bash
 inspect_cert () {
-  sub_selector='\(.extensions.subject_key_id | .[0:16])... \(.subject_dn)'
-  iss_selector='\(.extensions.authority_key_id // "................" | .[0:16])... \(.issuer_dn)'
 
-  step certificate inspect --format json "$1" \
-    | jq -r "\"Issuer:  $iss_selector\",\"Subject: $sub_selector\""
+    sub_selector='\(.extensions.subject_key_id | .[0:16])... \(.subject_dn)'
+    iss_selector='\(.extensions.authority_key_id // "................" | .[0:16])... \(.issuer_dn)'
+    val_selector='\((.validity.start // .not_before // .notBefore)) → \((.validity.end // .not_after // .notAfter))'
+
+    local input="${1:--}"
+
+    step certificate inspect --bundle --format json "$input" \
+    | jq -r '
+        # Handle both array (bundle) and single object
+        (if type == "array" then .[] else . end)
+        | select(type == "object")
+        | "Issuer:  '"$iss_selector"'",
+          "Subject: '"$sub_selector"'",
+          "Valid:   '"$val_selector"'",
+          "" 
+      '
 }
 ```
 
@@ -627,7 +599,8 @@ We should see something like this:
 
 ```text {class=disable-copy}
 Issuer:  ................... CN=root.linkerd.cluster.local
-Subject: 5c455d3e9bd77e91... CN=root.linkerd.cluster.local
+Subject: 421a7aa8e0c92dd0... CN=root.linkerd.cluster.local
+Valid:   2025-12-16T18:19:30Z → 2025-12-16T20:19:30Z
 ```
 
 where the `Subject`'s key fingerprint - the hex number on the second line - will
@@ -697,8 +670,9 @@ kubectl get secret -n linkerd linkerd-identity-issuer \
 Here, we should see something like
 
 ```text {class=disable-copy}
-Issuer:  5c455d3e9bd77e91... CN=root.linkerd.cluster.local
-Subject: 56bfe071553c16ad... CN=identity.linkerd.cluster.local
+Issuer:  421a7aa8e0c92dd0... CN=root.linkerd.cluster.local
+Subject: 76fc76842fff67f7... CN=identity.linkerd.cluster.local
+Valid:   2025-12-16T19:05:55Z → 2025-12-16T20:05:55Z
 ```
 
 where the `Issuer` line should be _exactly_ the same as the `Subject` line from
@@ -792,7 +766,7 @@ work of actually rotating the trust anchor, it can't trigger the needed
 restarts.
 
 This means that the simplest way to handle trust anchor rotation is
-to \*_trigger the rotation manually_ whenever it's convenient for you so that
+to _trigger the rotation manually_ whenever it's convenient for you so that
 you can manage the trust bundle and restarts while letting cert-manager manage
 the trust anchor certificate.
 
@@ -800,10 +774,12 @@ The process of actually doing this is straightforward, but again, there are
 several steps:
 
 1. Trigger trust anchor rotation
-2. Trigger identity issuer rotation
-3. Restart the control plane
-4. Restart the data plane
-5. Remove the old anchor from the trust bundle
+2. Restart the control plane
+3. Restart the data plane
+4. Trigger identity issuer rotation
+5. Restart the control plane
+6. Restart the data plane
+7. Remove the old anchor from the trust bundle
 
 {{< note >}}
 
@@ -842,15 +818,13 @@ kubectl get secret -n cert-manager linkerd-previous-anchor \
     | base64 -d | inspect_cert
 ```
 
-Additionally, the `linkerd-identity-trust-roots` ConfigMap should now contain
-the Subject keys from both Secrets. (We can't use `inspect_cert` for this since
-there are two keys.)
+Verify that the `linkerd-identity-trust-roots` ConfigMap now contains
+the Subject keys from both Secrets.
 
 ```bash
 kubectl get configmap -n linkerd linkerd-identity-trust-roots \
         -o jsonpath='{ .data.ca-bundle\.crt }' \
-        | step certificate inspect --bundle --format json \
-        | jq -r ".[] | \"Subject: \(.extensions.subject_key_id | .[0:16])... \(.subject_dn)\""
+        | inspect_cert
 ```
 
 Note that mTLS communication is still working fine at this point. All the
@@ -858,7 +832,25 @@ proxies in the data plane are still using the old identity issuer, signed by the
 old trust anchor, and that trust anchor is still present in
 `linkerd-identity-trust-roots`.
 
-#### 2. Triggering identity issuer rotation
+#### 2. Restart the control plane
+
+Restart the control plane with `kubectl rollout restart`:
+
+```bash
+kubectl rollout restart -n linkerd deploy
+kubectl rollout status -n linkerd deploy
+```
+
+This will cause the control plane to pick up the new trust anchor bundle.
+
+#### 3. Restart the data plane
+
+At this point, you'll need to restart your workloads as well, to force the
+proxies to have the new trust anchor bundle. The exact mechanism to do this
+will depend on your workloads, but it's often just `kubectl rollout restart` for
+each of your application namespaces.
+
+#### 4. Triggering identity issuer rotation
 
 Everything is still using the old identity issuer because, strangely, manually
 triggering cert-manager to rotate the trust anchor does not automatically rotate
@@ -887,9 +879,9 @@ kubectl get secret -n linkerd linkerd-identity-issuer \
     | base64 -d | inspect_cert
 ```
 
-#### 3. Restart the control plane
+#### 5. Restart the control plane
 
-Restart the control plane with `kubectl rollout restart`:
+Restart the control plane again with `kubectl rollout restart`:
 
 ```bash
 kubectl rollout restart -n linkerd deploy
@@ -899,14 +891,14 @@ kubectl rollout status -n linkerd deploy
 This will cause the control plane to pick up the new trust anchor and identity
 issuer.
 
-#### 4. Restart the data plane
+#### 6. Restart the data plane
 
-At this point, you'll need to restart your workloads as well, to force the
-proxies to switch to the new identity issuer. The exact mechanism to do this
-when depend on your workloads, but it's often just `kubectl rollout restart` for
-each of your application namespaces.
+Again, you'll need to restart your workloads, to force the
+proxies to switch to the new identity issuer signed by the new trust anchor.
+The exact mechanism to do this will depend on your workloads, but it's often
+just `kubectl rollout restart` for each of your application namespaces.
 
-#### 5. Remove the old anchor from the trust bundle
+#### 7. Remove the old anchor from the trust bundle
 
 One last step: once everything is restarted, you'll need to remove the old trust
 anchor from the trust bundle. To do this, just copy the `linkerd-trust-anchor`
@@ -933,14 +925,15 @@ You can doublecheck this with `kubectl` again:
 ```bash
 kubectl get configmap -n linkerd linkerd-identity-trust-roots \
         -o jsonpath='{ .data.ca-bundle\.crt }' \
-        | step certificate inspect --format json \
-        | jq -r "\"Subject: \(.extensions.subject_key_id | .[0:16])... \(.subject_dn)\""
+        | inspect_cert
 ```
 
 and you should only see the single ID of the current trust anchor.
 
 At this point rotation is complete: everything is using the new trust anchor,
-and the old trust anchor is no longer trusted.
+and the old trust anchor is no longer trusted. You will need to restart your
+workloads one more time so that they are aware of only the one trust anchor
+that's still in use.
 
 ## See also
 
diff --git a/linkerd.io/content/2.14/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.14/tasks/automatically-rotating-control-plane-tls-credentials.md
index 99f8dafbb9..2e356b0df8 100644
--- a/linkerd.io/content/2.14/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.14/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -148,46 +148,6 @@ helm install \
   --wait
 ```
 
-Finally, we'll need to update cert-manager's RBAC permissions. By default
-cert-manager will only create certificate secrets in the namespace where it is
-installed. Linkerd, however, requires its identity issuer to be created in the
-`linkerd` namespace. To allow this, we create a `ServiceAccount` for
-cert-manager in the `linkerd` namespace with the required permissions.
-
-```bash
-kubectl apply -f - <<EOF
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: cert-manager
-  namespace: linkerd
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: Role
-metadata:
-  name: cert-manager-secret-creator
-  namespace: linkerd
-rules:
-  - apiGroups: [""]
-    resources: ["secrets"]
-    verbs: ["create", "get", "update", "patch"]
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: RoleBinding
-metadata:
-  name: cert-manager-secret-creator-binding
-  namespace: linkerd
-subjects:
-  - kind: ServiceAccount
-    name: cert-manager
-    namespace: linkerd
-roleRef:
-  kind: Role
-  name: cert-manager-secret-creator
-  apiGroup: rbac.authorization.k8s.io
-EOF
-```
-
 ### 3. Configure cert-manager to create the trust anchor
 
 As described in Buoyant's
@@ -609,11 +569,23 @@ another:
 
 ```bash
 inspect_cert () {
-  sub_selector='\(.extensions.subject_key_id | .[0:16])... \(.subject_dn)'
-  iss_selector='\(.extensions.authority_key_id // "................" | .[0:16])... \(.issuer_dn)'
 
-  step certificate inspect --format json "$1" \
-    | jq -r "\"Issuer:  $iss_selector\",\"Subject: $sub_selector\""
+    sub_selector='\(.extensions.subject_key_id | .[0:16])... \(.subject_dn)'
+    iss_selector='\(.extensions.authority_key_id // "................" | .[0:16])... \(.issuer_dn)'
+    val_selector='\((.validity.start // .not_before // .notBefore)) → \((.validity.end // .not_after // .notAfter))'
+
+    local input="${1:--}"
+
+    step certificate inspect --bundle --format json "$input" \
+    | jq -r '
+        # Handle both array (bundle) and single object
+        (if type == "array" then .[] else . end)
+        | select(type == "object")
+        | "Issuer:  '"$iss_selector"'",
+          "Subject: '"$sub_selector"'",
+          "Valid:   '"$val_selector"'",
+          "" 
+      '
 }
 ```
 
@@ -627,7 +599,8 @@ We should see something like this:
 
 ```text {class=disable-copy}
 Issuer:  ................... CN=root.linkerd.cluster.local
-Subject: 5c455d3e9bd77e91... CN=root.linkerd.cluster.local
+Subject: 421a7aa8e0c92dd0... CN=root.linkerd.cluster.local
+Valid:   2025-12-16T18:19:30Z → 2025-12-16T20:19:30Z
 ```
 
 where the `Subject`'s key fingerprint - the hex number on the second line - will
@@ -697,8 +670,9 @@ kubectl get secret -n linkerd linkerd-identity-issuer \
 Here, we should see something like
 
 ```text {class=disable-copy}
-Issuer:  5c455d3e9bd77e91... CN=root.linkerd.cluster.local
-Subject: 56bfe071553c16ad... CN=identity.linkerd.cluster.local
+Issuer:  421a7aa8e0c92dd0... CN=root.linkerd.cluster.local
+Subject: 76fc76842fff67f7... CN=identity.linkerd.cluster.local
+Valid:   2025-12-16T19:05:55Z → 2025-12-16T20:05:55Z
 ```
 
 where the `Issuer` line should be _exactly_ the same as the `Subject` line from
@@ -792,7 +766,7 @@ work of actually rotating the trust anchor, it can't trigger the needed
 restarts.
 
 This means that the simplest way to handle trust anchor rotation is
-to \*_trigger the rotation manually_ whenever it's convenient for you so that
+to _trigger the rotation manually_ whenever it's convenient for you so that
 you can manage the trust bundle and restarts while letting cert-manager manage
 the trust anchor certificate.
 
@@ -800,10 +774,12 @@ The process of actually doing this is straightforward, but again, there are
 several steps:
 
 1. Trigger trust anchor rotation
-2. Trigger identity issuer rotation
-3. Restart the control plane
-4. Restart the data plane
-5. Remove the old anchor from the trust bundle
+2. Restart the control plane
+3. Restart the data plane
+4. Trigger identity issuer rotation
+5. Restart the control plane
+6. Restart the data plane
+7. Remove the old anchor from the trust bundle
 
 {{< note >}}
 
@@ -842,15 +818,13 @@ kubectl get secret -n cert-manager linkerd-previous-anchor \
     | base64 -d | inspect_cert
 ```
 
-Additionally, the `linkerd-identity-trust-roots` ConfigMap should now contain
-the Subject keys from both Secrets. (We can't use `inspect_cert` for this since
-there are two keys.)
+Verify that the `linkerd-identity-trust-roots` ConfigMap now contains
+the Subject keys from both Secrets.
 
 ```bash
 kubectl get configmap -n linkerd linkerd-identity-trust-roots \
         -o jsonpath='{ .data.ca-bundle\.crt }' \
-        | step certificate inspect --bundle --format json \
-        | jq -r ".[] | \"Subject: \(.extensions.subject_key_id | .[0:16])... \(.subject_dn)\""
+        | inspect_cert
 ```
 
 Note that mTLS communication is still working fine at this point. All the
@@ -858,7 +832,25 @@ proxies in the data plane are still using the old identity issuer, signed by the
 old trust anchor, and that trust anchor is still present in
 `linkerd-identity-trust-roots`.
 
-#### 2. Triggering identity issuer rotation
+#### 2. Restart the control plane
+
+Restart the control plane with `kubectl rollout restart`:
+
+```bash
+kubectl rollout restart -n linkerd deploy
+kubectl rollout status -n linkerd deploy
+```
+
+This will cause the control plane to pick up the new trust anchor bundle.
+
+#### 3. Restart the data plane
+
+At this point, you'll need to restart your workloads as well, to force the
+proxies to have the new trust anchor bundle. The exact mechanism to do this
+will depend on your workloads, but it's often just `kubectl rollout restart` for
+each of your application namespaces.
+
+#### 4. Triggering identity issuer rotation
 
 Everything is still using the old identity issuer because, strangely, manually
 triggering cert-manager to rotate the trust anchor does not automatically rotate
@@ -887,9 +879,9 @@ kubectl get secret -n linkerd linkerd-identity-issuer \
     | base64 -d | inspect_cert
 ```
 
-#### 3. Restart the control plane
+#### 5. Restart the control plane
 
-Restart the control plane with `kubectl rollout restart`:
+Restart the control plane again with `kubectl rollout restart`:
 
 ```bash
 kubectl rollout restart -n linkerd deploy
@@ -899,14 +891,14 @@ kubectl rollout status -n linkerd deploy
 This will cause the control plane to pick up the new trust anchor and identity
 issuer.
 
-#### 4. Restart the data plane
+#### 6. Restart the data plane
 
-At this point, you'll need to restart your workloads as well, to force the
-proxies to switch to the new identity issuer. The exact mechanism to do this
-when depend on your workloads, but it's often just `kubectl rollout restart` for
-each of your application namespaces.
+Again, you'll need to restart your workloads, to force the
+proxies to switch to the new identity issuer signed by the new trust anchor.
+The exact mechanism to do this will depend on your workloads, but it's often
+just `kubectl rollout restart` for each of your application namespaces.
 
-#### 5. Remove the old anchor from the trust bundle
+#### 7. Remove the old anchor from the trust bundle
 
 One last step: once everything is restarted, you'll need to remove the old trust
 anchor from the trust bundle. To do this, just copy the `linkerd-trust-anchor`
@@ -933,14 +925,15 @@ You can doublecheck this with `kubectl` again:
 ```bash
 kubectl get configmap -n linkerd linkerd-identity-trust-roots \
         -o jsonpath='{ .data.ca-bundle\.crt }' \
-        | step certificate inspect --format json \
-        | jq -r "\"Subject: \(.extensions.subject_key_id | .[0:16])... \(.subject_dn)\""
+        | inspect_cert
 ```
 
 and you should only see the single ID of the current trust anchor.
 
 At this point rotation is complete: everything is using the new trust anchor,
-and the old trust anchor is no longer trusted.
+and the old trust anchor is no longer trusted. You will need to restart your
+workloads one more time so that they are aware of only the one trust anchor
+that's still in use.
 
 ## See also
 
diff --git a/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
index 99f8dafbb9..2e356b0df8 100644
--- a/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.15/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -148,46 +148,6 @@ helm install \
   --wait
 ```
 
-Finally, we'll need to update cert-manager's RBAC permissions. By default
-cert-manager will only create certificate secrets in the namespace where it is
-installed. Linkerd, however, requires its identity issuer to be created in the
-`linkerd` namespace. To allow this, we create a `ServiceAccount` for
-cert-manager in the `linkerd` namespace with the required permissions.
-
-```bash
-kubectl apply -f - <<EOF
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: cert-manager
-  namespace: linkerd
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: Role
-metadata:
-  name: cert-manager-secret-creator
-  namespace: linkerd
-rules:
-  - apiGroups: [""]
-    resources: ["secrets"]
-    verbs: ["create", "get", "update", "patch"]
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: RoleBinding
-metadata:
-  name: cert-manager-secret-creator-binding
-  namespace: linkerd
-subjects:
-  - kind: ServiceAccount
-    name: cert-manager
-    namespace: linkerd
-roleRef:
-  kind: Role
-  name: cert-manager-secret-creator
-  apiGroup: rbac.authorization.k8s.io
-EOF
-```
-
 ### 3. Configure cert-manager to create the trust anchor
 
 As described in Buoyant's
@@ -609,11 +569,23 @@ another:
 
 ```bash
 inspect_cert () {
-  sub_selector='\(.extensions.subject_key_id | .[0:16])... \(.subject_dn)'
-  iss_selector='\(.extensions.authority_key_id // "................" | .[0:16])... \(.issuer_dn)'
 
-  step certificate inspect --format json "$1" \
-    | jq -r "\"Issuer:  $iss_selector\",\"Subject: $sub_selector\""
+    sub_selector='\(.extensions.subject_key_id | .[0:16])... \(.subject_dn)'
+    iss_selector='\(.extensions.authority_key_id // "................" | .[0:16])... \(.issuer_dn)'
+    val_selector='\((.validity.start // .not_before // .notBefore)) → \((.validity.end // .not_after // .notAfter))'
+
+    local input="${1:--}"
+
+    step certificate inspect --bundle --format json "$input" \
+    | jq -r '
+        # Handle both array (bundle) and single object
+        (if type == "array" then .[] else . end)
+        | select(type == "object")
+        | "Issuer:  '"$iss_selector"'",
+          "Subject: '"$sub_selector"'",
+          "Valid:   '"$val_selector"'",
+          "" 
+      '
 }
 ```
 
@@ -627,7 +599,8 @@ We should see something like this:
 
 ```text {class=disable-copy}
 Issuer:  ................... CN=root.linkerd.cluster.local
-Subject: 5c455d3e9bd77e91... CN=root.linkerd.cluster.local
+Subject: 421a7aa8e0c92dd0... CN=root.linkerd.cluster.local
+Valid:   2025-12-16T18:19:30Z → 2025-12-16T20:19:30Z
 ```
 
 where the `Subject`'s key fingerprint - the hex number on the second line - will
@@ -697,8 +670,9 @@ kubectl get secret -n linkerd linkerd-identity-issuer \
 Here, we should see something like
 
 ```text {class=disable-copy}
-Issuer:  5c455d3e9bd77e91... CN=root.linkerd.cluster.local
-Subject: 56bfe071553c16ad... CN=identity.linkerd.cluster.local
+Issuer:  421a7aa8e0c92dd0... CN=root.linkerd.cluster.local
+Subject: 76fc76842fff67f7... CN=identity.linkerd.cluster.local
+Valid:   2025-12-16T19:05:55Z → 2025-12-16T20:05:55Z
 ```
 
 where the `Issuer` line should be _exactly_ the same as the `Subject` line from
@@ -792,7 +766,7 @@ work of actually rotating the trust anchor, it can't trigger the needed
 restarts.
 
 This means that the simplest way to handle trust anchor rotation is
-to \*_trigger the rotation manually_ whenever it's convenient for you so that
+to _trigger the rotation manually_ whenever it's convenient for you so that
 you can manage the trust bundle and restarts while letting cert-manager manage
 the trust anchor certificate.
 
@@ -800,10 +774,12 @@ The process of actually doing this is straightforward, but again, there are
 several steps:
 
 1. Trigger trust anchor rotation
-2. Trigger identity issuer rotation
-3. Restart the control plane
-4. Restart the data plane
-5. Remove the old anchor from the trust bundle
+2. Restart the control plane
+3. Restart the data plane
+4. Trigger identity issuer rotation
+5. Restart the control plane
+6. Restart the data plane
+7. Remove the old anchor from the trust bundle
 
 {{< note >}}
 
@@ -842,15 +818,13 @@ kubectl get secret -n cert-manager linkerd-previous-anchor \
     | base64 -d | inspect_cert
 ```
 
-Additionally, the `linkerd-identity-trust-roots` ConfigMap should now contain
-the Subject keys from both Secrets. (We can't use `inspect_cert` for this since
-there are two keys.)
+Verify that the `linkerd-identity-trust-roots` ConfigMap now contains
+the Subject keys from both Secrets.
 
 ```bash
 kubectl get configmap -n linkerd linkerd-identity-trust-roots \
         -o jsonpath='{ .data.ca-bundle\.crt }' \
-        | step certificate inspect --bundle --format json \
-        | jq -r ".[] | \"Subject: \(.extensions.subject_key_id | .[0:16])... \(.subject_dn)\""
+        | inspect_cert
 ```
 
 Note that mTLS communication is still working fine at this point. All the
@@ -858,7 +832,25 @@ proxies in the data plane are still using the old identity issuer, signed by the
 old trust anchor, and that trust anchor is still present in
 `linkerd-identity-trust-roots`.
 
-#### 2. Triggering identity issuer rotation
+#### 2. Restart the control plane
+
+Restart the control plane with `kubectl rollout restart`:
+
+```bash
+kubectl rollout restart -n linkerd deploy
+kubectl rollout status -n linkerd deploy
+```
+
+This will cause the control plane to pick up the new trust anchor bundle.
+
+#### 3. Restart the data plane
+
+At this point, you'll need to restart your workloads as well, to force the
+proxies to have the new trust anchor bundle. The exact mechanism to do this
+will depend on your workloads, but it's often just `kubectl rollout restart` for
+each of your application namespaces.
+
+#### 4. Triggering identity issuer rotation
 
 Everything is still using the old identity issuer because, strangely, manually
 triggering cert-manager to rotate the trust anchor does not automatically rotate
@@ -887,9 +879,9 @@ kubectl get secret -n linkerd linkerd-identity-issuer \
     | base64 -d | inspect_cert
 ```
 
-#### 3. Restart the control plane
+#### 5. Restart the control plane
 
-Restart the control plane with `kubectl rollout restart`:
+Restart the control plane again with `kubectl rollout restart`:
 
 ```bash
 kubectl rollout restart -n linkerd deploy
@@ -899,14 +891,14 @@ kubectl rollout status -n linkerd deploy
 This will cause the control plane to pick up the new trust anchor and identity
 issuer.
 
-#### 4. Restart the data plane
+#### 6. Restart the data plane
 
-At this point, you'll need to restart your workloads as well, to force the
-proxies to switch to the new identity issuer. The exact mechanism to do this
-when depend on your workloads, but it's often just `kubectl rollout restart` for
-each of your application namespaces.
+Again, you'll need to restart your workloads, to force the
+proxies to switch to the new identity issuer signed by the new trust anchor.
+The exact mechanism to do this will depend on your workloads, but it's often
+just `kubectl rollout restart` for each of your application namespaces.
 
-#### 5. Remove the old anchor from the trust bundle
+#### 7. Remove the old anchor from the trust bundle
 
 One last step: once everything is restarted, you'll need to remove the old trust
 anchor from the trust bundle. To do this, just copy the `linkerd-trust-anchor`
@@ -933,14 +925,15 @@ You can doublecheck this with `kubectl` again:
 ```bash
 kubectl get configmap -n linkerd linkerd-identity-trust-roots \
         -o jsonpath='{ .data.ca-bundle\.crt }' \
-        | step certificate inspect --format json \
-        | jq -r "\"Subject: \(.extensions.subject_key_id | .[0:16])... \(.subject_dn)\""
+        | inspect_cert
 ```
 
 and you should only see the single ID of the current trust anchor.
 
 At this point rotation is complete: everything is using the new trust anchor,
-and the old trust anchor is no longer trusted.
+and the old trust anchor is no longer trusted. You will need to restart your
+workloads one more time so that they are aware of only the one trust anchor
+that's still in use.
 
 ## See also
 
diff --git a/linkerd.io/content/2.16/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.16/tasks/automatically-rotating-control-plane-tls-credentials.md
index 99f8dafbb9..2e356b0df8 100644
--- a/linkerd.io/content/2.16/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.16/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -148,46 +148,6 @@ helm install \
   --wait
 ```
 
-Finally, we'll need to update cert-manager's RBAC permissions. By default
-cert-manager will only create certificate secrets in the namespace where it is
-installed. Linkerd, however, requires its identity issuer to be created in the
-`linkerd` namespace. To allow this, we create a `ServiceAccount` for
-cert-manager in the `linkerd` namespace with the required permissions.
-
-```bash
-kubectl apply -f - <<EOF
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: cert-manager
-  namespace: linkerd
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: Role
-metadata:
-  name: cert-manager-secret-creator
-  namespace: linkerd
-rules:
-  - apiGroups: [""]
-    resources: ["secrets"]
-    verbs: ["create", "get", "update", "patch"]
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: RoleBinding
-metadata:
-  name: cert-manager-secret-creator-binding
-  namespace: linkerd
-subjects:
-  - kind: ServiceAccount
-    name: cert-manager
-    namespace: linkerd
-roleRef:
-  kind: Role
-  name: cert-manager-secret-creator
-  apiGroup: rbac.authorization.k8s.io
-EOF
-```
-
 ### 3. Configure cert-manager to create the trust anchor
 
 As described in Buoyant's
@@ -609,11 +569,23 @@ another:
 
 ```bash
 inspect_cert () {
-  sub_selector='\(.extensions.subject_key_id | .[0:16])... \(.subject_dn)'
-  iss_selector='\(.extensions.authority_key_id // "................" | .[0:16])... \(.issuer_dn)'
 
-  step certificate inspect --format json "$1" \
-    | jq -r "\"Issuer:  $iss_selector\",\"Subject: $sub_selector\""
+    sub_selector='\(.extensions.subject_key_id | .[0:16])... \(.subject_dn)'
+    iss_selector='\(.extensions.authority_key_id // "................" | .[0:16])... \(.issuer_dn)'
+    val_selector='\((.validity.start // .not_before // .notBefore)) → \((.validity.end // .not_after // .notAfter))'
+
+    local input="${1:--}"
+
+    step certificate inspect --bundle --format json "$input" \
+    | jq -r '
+        # Handle both array (bundle) and single object
+        (if type == "array" then .[] else . end)
+        | select(type == "object")
+        | "Issuer:  '"$iss_selector"'",
+          "Subject: '"$sub_selector"'",
+          "Valid:   '"$val_selector"'",
+          "" 
+      '
 }
 ```
 
@@ -627,7 +599,8 @@ We should see something like this:
 
 ```text {class=disable-copy}
 Issuer:  ................... CN=root.linkerd.cluster.local
-Subject: 5c455d3e9bd77e91... CN=root.linkerd.cluster.local
+Subject: 421a7aa8e0c92dd0... CN=root.linkerd.cluster.local
+Valid:   2025-12-16T18:19:30Z → 2025-12-16T20:19:30Z
 ```
 
 where the `Subject`'s key fingerprint - the hex number on the second line - will
@@ -697,8 +670,9 @@ kubectl get secret -n linkerd linkerd-identity-issuer \
 Here, we should see something like
 
 ```text {class=disable-copy}
-Issuer:  5c455d3e9bd77e91... CN=root.linkerd.cluster.local
-Subject: 56bfe071553c16ad... CN=identity.linkerd.cluster.local
+Issuer:  421a7aa8e0c92dd0... CN=root.linkerd.cluster.local
+Subject: 76fc76842fff67f7... CN=identity.linkerd.cluster.local
+Valid:   2025-12-16T19:05:55Z → 2025-12-16T20:05:55Z
 ```
 
 where the `Issuer` line should be _exactly_ the same as the `Subject` line from
@@ -792,7 +766,7 @@ work of actually rotating the trust anchor, it can't trigger the needed
 restarts.
 
 This means that the simplest way to handle trust anchor rotation is
-to \*_trigger the rotation manually_ whenever it's convenient for you so that
+to _trigger the rotation manually_ whenever it's convenient for you so that
 you can manage the trust bundle and restarts while letting cert-manager manage
 the trust anchor certificate.
 
@@ -800,10 +774,12 @@ The process of actually doing this is straightforward, but again, there are
 several steps:
 
 1. Trigger trust anchor rotation
-2. Trigger identity issuer rotation
-3. Restart the control plane
-4. Restart the data plane
-5. Remove the old anchor from the trust bundle
+2. Restart the control plane
+3. Restart the data plane
+4. Trigger identity issuer rotation
+5. Restart the control plane
+6. Restart the data plane
+7. Remove the old anchor from the trust bundle
 
 {{< note >}}
 
@@ -842,15 +818,13 @@ kubectl get secret -n cert-manager linkerd-previous-anchor \
     | base64 -d | inspect_cert
 ```
 
-Additionally, the `linkerd-identity-trust-roots` ConfigMap should now contain
-the Subject keys from both Secrets. (We can't use `inspect_cert` for this since
-there are two keys.)
+Verify that the `linkerd-identity-trust-roots` ConfigMap now contains
+the Subject keys from both Secrets.
 
 ```bash
 kubectl get configmap -n linkerd linkerd-identity-trust-roots \
         -o jsonpath='{ .data.ca-bundle\.crt }' \
-        | step certificate inspect --bundle --format json \
-        | jq -r ".[] | \"Subject: \(.extensions.subject_key_id | .[0:16])... \(.subject_dn)\""
+        | inspect_cert
 ```
 
 Note that mTLS communication is still working fine at this point. All the
@@ -858,7 +832,25 @@ proxies in the data plane are still using the old identity issuer, signed by the
 old trust anchor, and that trust anchor is still present in
 `linkerd-identity-trust-roots`.
 
-#### 2. Triggering identity issuer rotation
+#### 2. Restart the control plane
+
+Restart the control plane with `kubectl rollout restart`:
+
+```bash
+kubectl rollout restart -n linkerd deploy
+kubectl rollout status -n linkerd deploy
+```
+
+This will cause the control plane to pick up the new trust anchor bundle.
+
+#### 3. Restart the data plane
+
+At this point, you'll need to restart your workloads as well, to force the
+proxies to have the new trust anchor bundle. The exact mechanism to do this
+will depend on your workloads, but it's often just `kubectl rollout restart` for
+each of your application namespaces.
+
+#### 4. Triggering identity issuer rotation
 
 Everything is still using the old identity issuer because, strangely, manually
 triggering cert-manager to rotate the trust anchor does not automatically rotate
@@ -887,9 +879,9 @@ kubectl get secret -n linkerd linkerd-identity-issuer \
     | base64 -d | inspect_cert
 ```
 
-#### 3. Restart the control plane
+#### 5. Restart the control plane
 
-Restart the control plane with `kubectl rollout restart`:
+Restart the control plane again with `kubectl rollout restart`:
 
 ```bash
 kubectl rollout restart -n linkerd deploy
@@ -899,14 +891,14 @@ kubectl rollout status -n linkerd deploy
 This will cause the control plane to pick up the new trust anchor and identity
 issuer.
 
-#### 4. Restart the data plane
+#### 6. Restart the data plane
 
-At this point, you'll need to restart your workloads as well, to force the
-proxies to switch to the new identity issuer. The exact mechanism to do this
-when depend on your workloads, but it's often just `kubectl rollout restart` for
-each of your application namespaces.
+Again, you'll need to restart your workloads, to force the
+proxies to switch to the new identity issuer signed by the new trust anchor.
+The exact mechanism to do this will depend on your workloads, but it's often
+just `kubectl rollout restart` for each of your application namespaces.
 
-#### 5. Remove the old anchor from the trust bundle
+#### 7. Remove the old anchor from the trust bundle
 
 One last step: once everything is restarted, you'll need to remove the old trust
 anchor from the trust bundle. To do this, just copy the `linkerd-trust-anchor`
@@ -933,14 +925,15 @@ You can doublecheck this with `kubectl` again:
 ```bash
 kubectl get configmap -n linkerd linkerd-identity-trust-roots \
         -o jsonpath='{ .data.ca-bundle\.crt }' \
-        | step certificate inspect --format json \
-        | jq -r "\"Subject: \(.extensions.subject_key_id | .[0:16])... \(.subject_dn)\""
+        | inspect_cert
 ```
 
 and you should only see the single ID of the current trust anchor.
 
 At this point rotation is complete: everything is using the new trust anchor,
-and the old trust anchor is no longer trusted.
+and the old trust anchor is no longer trusted. You will need to restart your
+workloads one more time so that they are aware of only the one trust anchor
+that's still in use.
 
 ## See also
 
diff --git a/linkerd.io/content/2.17/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.17/tasks/automatically-rotating-control-plane-tls-credentials.md
index 99f8dafbb9..2e356b0df8 100644
--- a/linkerd.io/content/2.17/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.17/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -148,46 +148,6 @@ helm install \
   --wait
 ```
 
-Finally, we'll need to update cert-manager's RBAC permissions. By default
-cert-manager will only create certificate secrets in the namespace where it is
-installed. Linkerd, however, requires its identity issuer to be created in the
-`linkerd` namespace. To allow this, we create a `ServiceAccount` for
-cert-manager in the `linkerd` namespace with the required permissions.
-
-```bash
-kubectl apply -f - <<EOF
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: cert-manager
-  namespace: linkerd
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: Role
-metadata:
-  name: cert-manager-secret-creator
-  namespace: linkerd
-rules:
-  - apiGroups: [""]
-    resources: ["secrets"]
-    verbs: ["create", "get", "update", "patch"]
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: RoleBinding
-metadata:
-  name: cert-manager-secret-creator-binding
-  namespace: linkerd
-subjects:
-  - kind: ServiceAccount
-    name: cert-manager
-    namespace: linkerd
-roleRef:
-  kind: Role
-  name: cert-manager-secret-creator
-  apiGroup: rbac.authorization.k8s.io
-EOF
-```
-
 ### 3. Configure cert-manager to create the trust anchor
 
 As described in Buoyant's
@@ -609,11 +569,23 @@ another:
 
 ```bash
 inspect_cert () {
-  sub_selector='\(.extensions.subject_key_id | .[0:16])... \(.subject_dn)'
-  iss_selector='\(.extensions.authority_key_id // "................" | .[0:16])... \(.issuer_dn)'
 
-  step certificate inspect --format json "$1" \
-    | jq -r "\"Issuer:  $iss_selector\",\"Subject: $sub_selector\""
+    sub_selector='\(.extensions.subject_key_id | .[0:16])... \(.subject_dn)'
+    iss_selector='\(.extensions.authority_key_id // "................" | .[0:16])... \(.issuer_dn)'
+    val_selector='\((.validity.start // .not_before // .notBefore)) → \((.validity.end // .not_after // .notAfter))'
+
+    local input="${1:--}"
+
+    step certificate inspect --bundle --format json "$input" \
+    | jq -r '
+        # Handle both array (bundle) and single object
+        (if type == "array" then .[] else . end)
+        | select(type == "object")
+        | "Issuer:  '"$iss_selector"'",
+          "Subject: '"$sub_selector"'",
+          "Valid:   '"$val_selector"'",
+          "" 
+      '
 }
 ```
 
@@ -627,7 +599,8 @@ We should see something like this:
 
 ```text {class=disable-copy}
 Issuer:  ................... CN=root.linkerd.cluster.local
-Subject: 5c455d3e9bd77e91... CN=root.linkerd.cluster.local
+Subject: 421a7aa8e0c92dd0... CN=root.linkerd.cluster.local
+Valid:   2025-12-16T18:19:30Z → 2025-12-16T20:19:30Z
 ```
 
 where the `Subject`'s key fingerprint - the hex number on the second line - will
@@ -697,8 +670,9 @@ kubectl get secret -n linkerd linkerd-identity-issuer \
 Here, we should see something like
 
 ```text {class=disable-copy}
-Issuer:  5c455d3e9bd77e91... CN=root.linkerd.cluster.local
-Subject: 56bfe071553c16ad... CN=identity.linkerd.cluster.local
+Issuer:  421a7aa8e0c92dd0... CN=root.linkerd.cluster.local
+Subject: 76fc76842fff67f7... CN=identity.linkerd.cluster.local
+Valid:   2025-12-16T19:05:55Z → 2025-12-16T20:05:55Z
 ```
 
 where the `Issuer` line should be _exactly_ the same as the `Subject` line from
@@ -792,7 +766,7 @@ work of actually rotating the trust anchor, it can't trigger the needed
 restarts.
 
 This means that the simplest way to handle trust anchor rotation is
-to \*_trigger the rotation manually_ whenever it's convenient for you so that
+to _trigger the rotation manually_ whenever it's convenient for you so that
 you can manage the trust bundle and restarts while letting cert-manager manage
 the trust anchor certificate.
 
@@ -800,10 +774,12 @@ The process of actually doing this is straightforward, but again, there are
 several steps:
 
 1. Trigger trust anchor rotation
-2. Trigger identity issuer rotation
-3. Restart the control plane
-4. Restart the data plane
-5. Remove the old anchor from the trust bundle
+2. Restart the control plane
+3. Restart the data plane
+4. Trigger identity issuer rotation
+5. Restart the control plane
+6. Restart the data plane
+7. Remove the old anchor from the trust bundle
 
 {{< note >}}
 
@@ -842,15 +818,13 @@ kubectl get secret -n cert-manager linkerd-previous-anchor \
     | base64 -d | inspect_cert
 ```
 
-Additionally, the `linkerd-identity-trust-roots` ConfigMap should now contain
-the Subject keys from both Secrets. (We can't use `inspect_cert` for this since
-there are two keys.)
+Verify that the `linkerd-identity-trust-roots` ConfigMap now contains
+the Subject keys from both Secrets.
 
 ```bash
 kubectl get configmap -n linkerd linkerd-identity-trust-roots \
         -o jsonpath='{ .data.ca-bundle\.crt }' \
-        | step certificate inspect --bundle --format json \
-        | jq -r ".[] | \"Subject: \(.extensions.subject_key_id | .[0:16])... \(.subject_dn)\""
+        | inspect_cert
 ```
 
 Note that mTLS communication is still working fine at this point. All the
@@ -858,7 +832,25 @@ proxies in the data plane are still using the old identity issuer, signed by the
 old trust anchor, and that trust anchor is still present in
 `linkerd-identity-trust-roots`.
 
-#### 2. Triggering identity issuer rotation
+#### 2. Restart the control plane
+
+Restart the control plane with `kubectl rollout restart`:
+
+```bash
+kubectl rollout restart -n linkerd deploy
+kubectl rollout status -n linkerd deploy
+```
+
+This will cause the control plane to pick up the new trust anchor bundle.
+
+#### 3. Restart the data plane
+
+At this point, you'll need to restart your workloads as well, to force the
+proxies to have the new trust anchor bundle. The exact mechanism to do this
+will depend on your workloads, but it's often just `kubectl rollout restart` for
+each of your application namespaces.
+
+#### 4. Triggering identity issuer rotation
 
 Everything is still using the old identity issuer because, strangely, manually
 triggering cert-manager to rotate the trust anchor does not automatically rotate
@@ -887,9 +879,9 @@ kubectl get secret -n linkerd linkerd-identity-issuer \
     | base64 -d | inspect_cert
 ```
 
-#### 3. Restart the control plane
+#### 5. Restart the control plane
 
-Restart the control plane with `kubectl rollout restart`:
+Restart the control plane again with `kubectl rollout restart`:
 
 ```bash
 kubectl rollout restart -n linkerd deploy
@@ -899,14 +891,14 @@ kubectl rollout status -n linkerd deploy
 This will cause the control plane to pick up the new trust anchor and identity
 issuer.
 
-#### 4. Restart the data plane
+#### 6. Restart the data plane
 
-At this point, you'll need to restart your workloads as well, to force the
-proxies to switch to the new identity issuer. The exact mechanism to do this
-when depend on your workloads, but it's often just `kubectl rollout restart` for
-each of your application namespaces.
+Again, you'll need to restart your workloads, to force the
+proxies to switch to the new identity issuer signed by the new trust anchor.
+The exact mechanism to do this will depend on your workloads, but it's often
+just `kubectl rollout restart` for each of your application namespaces.
 
-#### 5. Remove the old anchor from the trust bundle
+#### 7. Remove the old anchor from the trust bundle
 
 One last step: once everything is restarted, you'll need to remove the old trust
 anchor from the trust bundle. To do this, just copy the `linkerd-trust-anchor`
@@ -933,14 +925,15 @@ You can doublecheck this with `kubectl` again:
 ```bash
 kubectl get configmap -n linkerd linkerd-identity-trust-roots \
         -o jsonpath='{ .data.ca-bundle\.crt }' \
-        | step certificate inspect --format json \
-        | jq -r "\"Subject: \(.extensions.subject_key_id | .[0:16])... \(.subject_dn)\""
+        | inspect_cert
 ```
 
 and you should only see the single ID of the current trust anchor.
 
 At this point rotation is complete: everything is using the new trust anchor,
-and the old trust anchor is no longer trusted.
+and the old trust anchor is no longer trusted. You will need to restart your
+workloads one more time so that they are aware of only the one trust anchor
+that's still in use.
 
 ## See also
 
diff --git a/linkerd.io/content/2.18/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.18/tasks/automatically-rotating-control-plane-tls-credentials.md
index 99f8dafbb9..2e356b0df8 100644
--- a/linkerd.io/content/2.18/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.18/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -148,46 +148,6 @@ helm install \
   --wait
 ```
 
-Finally, we'll need to update cert-manager's RBAC permissions. By default
-cert-manager will only create certificate secrets in the namespace where it is
-installed. Linkerd, however, requires its identity issuer to be created in the
-`linkerd` namespace. To allow this, we create a `ServiceAccount` for
-cert-manager in the `linkerd` namespace with the required permissions.
-
-```bash
-kubectl apply -f - <<EOF
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: cert-manager
-  namespace: linkerd
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: Role
-metadata:
-  name: cert-manager-secret-creator
-  namespace: linkerd
-rules:
-  - apiGroups: [""]
-    resources: ["secrets"]
-    verbs: ["create", "get", "update", "patch"]
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: RoleBinding
-metadata:
-  name: cert-manager-secret-creator-binding
-  namespace: linkerd
-subjects:
-  - kind: ServiceAccount
-    name: cert-manager
-    namespace: linkerd
-roleRef:
-  kind: Role
-  name: cert-manager-secret-creator
-  apiGroup: rbac.authorization.k8s.io
-EOF
-```
-
 ### 3. Configure cert-manager to create the trust anchor
 
 As described in Buoyant's
@@ -609,11 +569,23 @@ another:
 
 ```bash
 inspect_cert () {
-  sub_selector='\(.extensions.subject_key_id | .[0:16])... \(.subject_dn)'
-  iss_selector='\(.extensions.authority_key_id // "................" | .[0:16])... \(.issuer_dn)'
 
-  step certificate inspect --format json "$1" \
-    | jq -r "\"Issuer:  $iss_selector\",\"Subject: $sub_selector\""
+    sub_selector='\(.extensions.subject_key_id | .[0:16])... \(.subject_dn)'
+    iss_selector='\(.extensions.authority_key_id // "................" | .[0:16])... \(.issuer_dn)'
+    val_selector='\((.validity.start // .not_before // .notBefore)) → \((.validity.end // .not_after // .notAfter))'
+
+    local input="${1:--}"
+
+    step certificate inspect --bundle --format json "$input" \
+    | jq -r '
+        # Handle both array (bundle) and single object
+        (if type == "array" then .[] else . end)
+        | select(type == "object")
+        | "Issuer:  '"$iss_selector"'",
+          "Subject: '"$sub_selector"'",
+          "Valid:   '"$val_selector"'",
+          "" 
+      '
 }
 ```
 
@@ -627,7 +599,8 @@ We should see something like this:
 
 ```text {class=disable-copy}
 Issuer:  ................... CN=root.linkerd.cluster.local
-Subject: 5c455d3e9bd77e91... CN=root.linkerd.cluster.local
+Subject: 421a7aa8e0c92dd0... CN=root.linkerd.cluster.local
+Valid:   2025-12-16T18:19:30Z → 2025-12-16T20:19:30Z
 ```
 
 where the `Subject`'s key fingerprint - the hex number on the second line - will
@@ -697,8 +670,9 @@ kubectl get secret -n linkerd linkerd-identity-issuer \
 Here, we should see something like
 
 ```text {class=disable-copy}
-Issuer:  5c455d3e9bd77e91... CN=root.linkerd.cluster.local
-Subject: 56bfe071553c16ad... CN=identity.linkerd.cluster.local
+Issuer:  421a7aa8e0c92dd0... CN=root.linkerd.cluster.local
+Subject: 76fc76842fff67f7... CN=identity.linkerd.cluster.local
+Valid:   2025-12-16T19:05:55Z → 2025-12-16T20:05:55Z
 ```
 
 where the `Issuer` line should be _exactly_ the same as the `Subject` line from
@@ -792,7 +766,7 @@ work of actually rotating the trust anchor, it can't trigger the needed
 restarts.
 
 This means that the simplest way to handle trust anchor rotation is
-to \*_trigger the rotation manually_ whenever it's convenient for you so that
+to _trigger the rotation manually_ whenever it's convenient for you so that
 you can manage the trust bundle and restarts while letting cert-manager manage
 the trust anchor certificate.
 
@@ -800,10 +774,12 @@ The process of actually doing this is straightforward, but again, there are
 several steps:
 
 1. Trigger trust anchor rotation
-2. Trigger identity issuer rotation
-3. Restart the control plane
-4. Restart the data plane
-5. Remove the old anchor from the trust bundle
+2. Restart the control plane
+3. Restart the data plane
+4. Trigger identity issuer rotation
+5. Restart the control plane
+6. Restart the data plane
+7. Remove the old anchor from the trust bundle
 
 {{< note >}}
 
@@ -842,15 +818,13 @@ kubectl get secret -n cert-manager linkerd-previous-anchor \
     | base64 -d | inspect_cert
 ```
 
-Additionally, the `linkerd-identity-trust-roots` ConfigMap should now contain
-the Subject keys from both Secrets. (We can't use `inspect_cert` for this since
-there are two keys.)
+Verify that the `linkerd-identity-trust-roots` ConfigMap now contains
+the Subject keys from both Secrets.
 
 ```bash
 kubectl get configmap -n linkerd linkerd-identity-trust-roots \
         -o jsonpath='{ .data.ca-bundle\.crt }' \
-        | step certificate inspect --bundle --format json \
-        | jq -r ".[] | \"Subject: \(.extensions.subject_key_id | .[0:16])... \(.subject_dn)\""
+        | inspect_cert
 ```
 
 Note that mTLS communication is still working fine at this point. All the
@@ -858,7 +832,25 @@ proxies in the data plane are still using the old identity issuer, signed by the
 old trust anchor, and that trust anchor is still present in
 `linkerd-identity-trust-roots`.
 
-#### 2. Triggering identity issuer rotation
+#### 2. Restart the control plane
+
+Restart the control plane with `kubectl rollout restart`:
+
+```bash
+kubectl rollout restart -n linkerd deploy
+kubectl rollout status -n linkerd deploy
+```
+
+This will cause the control plane to pick up the new trust anchor bundle.
+
+#### 3. Restart the data plane
+
+At this point, you'll need to restart your workloads as well, to force the
+proxies to have the new trust anchor bundle. The exact mechanism to do this
+will depend on your workloads, but it's often just `kubectl rollout restart` for
+each of your application namespaces.
+
+#### 4. Triggering identity issuer rotation
 
 Everything is still using the old identity issuer because, strangely, manually
 triggering cert-manager to rotate the trust anchor does not automatically rotate
@@ -887,9 +879,9 @@ kubectl get secret -n linkerd linkerd-identity-issuer \
     | base64 -d | inspect_cert
 ```
 
-#### 3. Restart the control plane
+#### 5. Restart the control plane
 
-Restart the control plane with `kubectl rollout restart`:
+Restart the control plane again with `kubectl rollout restart`:
 
 ```bash
 kubectl rollout restart -n linkerd deploy
@@ -899,14 +891,14 @@ kubectl rollout status -n linkerd deploy
 This will cause the control plane to pick up the new trust anchor and identity
 issuer.
 
-#### 4. Restart the data plane
+#### 6. Restart the data plane
 
-At this point, you'll need to restart your workloads as well, to force the
-proxies to switch to the new identity issuer. The exact mechanism to do this
-when depend on your workloads, but it's often just `kubectl rollout restart` for
-each of your application namespaces.
+Again, you'll need to restart your workloads, to force the
+proxies to switch to the new identity issuer signed by the new trust anchor.
+The exact mechanism to do this will depend on your workloads, but it's often
+just `kubectl rollout restart` for each of your application namespaces.
 
-#### 5. Remove the old anchor from the trust bundle
+#### 7. Remove the old anchor from the trust bundle
 
 One last step: once everything is restarted, you'll need to remove the old trust
 anchor from the trust bundle. To do this, just copy the `linkerd-trust-anchor`
@@ -933,14 +925,15 @@ You can doublecheck this with `kubectl` again:
 ```bash
 kubectl get configmap -n linkerd linkerd-identity-trust-roots \
         -o jsonpath='{ .data.ca-bundle\.crt }' \
-        | step certificate inspect --format json \
-        | jq -r "\"Subject: \(.extensions.subject_key_id | .[0:16])... \(.subject_dn)\""
+        | inspect_cert
 ```
 
 and you should only see the single ID of the current trust anchor.
 
 At this point rotation is complete: everything is using the new trust anchor,
-and the old trust anchor is no longer trusted.
+and the old trust anchor is no longer trusted. You will need to restart your
+workloads one more time so that they are aware of only the one trust anchor
+that's still in use.
 
 ## See also
 
diff --git a/linkerd.io/content/2.19/tasks/automatically-rotating-control-plane-tls-credentials.md b/linkerd.io/content/2.19/tasks/automatically-rotating-control-plane-tls-credentials.md
index 99f8dafbb9..2e356b0df8 100644
--- a/linkerd.io/content/2.19/tasks/automatically-rotating-control-plane-tls-credentials.md
+++ b/linkerd.io/content/2.19/tasks/automatically-rotating-control-plane-tls-credentials.md
@@ -148,46 +148,6 @@ helm install \
   --wait
 ```
 
-Finally, we'll need to update cert-manager's RBAC permissions. By default
-cert-manager will only create certificate secrets in the namespace where it is
-installed. Linkerd, however, requires its identity issuer to be created in the
-`linkerd` namespace. To allow this, we create a `ServiceAccount` for
-cert-manager in the `linkerd` namespace with the required permissions.
-
-```bash
-kubectl apply -f - <<EOF
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: cert-manager
-  namespace: linkerd
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: Role
-metadata:
-  name: cert-manager-secret-creator
-  namespace: linkerd
-rules:
-  - apiGroups: [""]
-    resources: ["secrets"]
-    verbs: ["create", "get", "update", "patch"]
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: RoleBinding
-metadata:
-  name: cert-manager-secret-creator-binding
-  namespace: linkerd
-subjects:
-  - kind: ServiceAccount
-    name: cert-manager
-    namespace: linkerd
-roleRef:
-  kind: Role
-  name: cert-manager-secret-creator
-  apiGroup: rbac.authorization.k8s.io
-EOF
-```
-
 ### 3. Configure cert-manager to create the trust anchor
 
 As described in Buoyant's
@@ -609,11 +569,23 @@ another:
 
 ```bash
 inspect_cert () {
-  sub_selector='\(.extensions.subject_key_id | .[0:16])... \(.subject_dn)'
-  iss_selector='\(.extensions.authority_key_id // "................" | .[0:16])... \(.issuer_dn)'
 
-  step certificate inspect --format json "$1" \
-    | jq -r "\"Issuer:  $iss_selector\",\"Subject: $sub_selector\""
+    sub_selector='\(.extensions.subject_key_id | .[0:16])... \(.subject_dn)'
+    iss_selector='\(.extensions.authority_key_id // "................" | .[0:16])... \(.issuer_dn)'
+    val_selector='\((.validity.start // .not_before // .notBefore)) → \((.validity.end // .not_after // .notAfter))'
+
+    local input="${1:--}"
+
+    step certificate inspect --bundle --format json "$input" \
+    | jq -r '
+        # Handle both array (bundle) and single object
+        (if type == "array" then .[] else . end)
+        | select(type == "object")
+        | "Issuer:  '"$iss_selector"'",
+          "Subject: '"$sub_selector"'",
+          "Valid:   '"$val_selector"'",
+          "" 
+      '
 }
 ```
 
@@ -627,7 +599,8 @@ We should see something like this:
 
 ```text {class=disable-copy}
 Issuer:  ................... CN=root.linkerd.cluster.local
-Subject: 5c455d3e9bd77e91... CN=root.linkerd.cluster.local
+Subject: 421a7aa8e0c92dd0... CN=root.linkerd.cluster.local
+Valid:   2025-12-16T18:19:30Z → 2025-12-16T20:19:30Z
 ```
 
 where the `Subject`'s key fingerprint - the hex number on the second line - will
@@ -697,8 +670,9 @@ kubectl get secret -n linkerd linkerd-identity-issuer \
 Here, we should see something like
 
 ```text {class=disable-copy}
-Issuer:  5c455d3e9bd77e91... CN=root.linkerd.cluster.local
-Subject: 56bfe071553c16ad... CN=identity.linkerd.cluster.local
+Issuer:  421a7aa8e0c92dd0... CN=root.linkerd.cluster.local
+Subject: 76fc76842fff67f7... CN=identity.linkerd.cluster.local
+Valid:   2025-12-16T19:05:55Z → 2025-12-16T20:05:55Z
 ```
 
 where the `Issuer` line should be _exactly_ the same as the `Subject` line from
@@ -792,7 +766,7 @@ work of actually rotating the trust anchor, it can't trigger the needed
 restarts.
 
 This means that the simplest way to handle trust anchor rotation is
-to \*_trigger the rotation manually_ whenever it's convenient for you so that
+to _trigger the rotation manually_ whenever it's convenient for you so that
 you can manage the trust bundle and restarts while letting cert-manager manage
 the trust anchor certificate.
 
@@ -800,10 +774,12 @@ The process of actually doing this is straightforward, but again, there are
 several steps:
 
 1. Trigger trust anchor rotation
-2. Trigger identity issuer rotation
-3. Restart the control plane
-4. Restart the data plane
-5. Remove the old anchor from the trust bundle
+2. Restart the control plane
+3. Restart the data plane
+4. Trigger identity issuer rotation
+5. Restart the control plane
+6. Restart the data plane
+7. Remove the old anchor from the trust bundle
 
 {{< note >}}
 
@@ -842,15 +818,13 @@ kubectl get secret -n cert-manager linkerd-previous-anchor \
     | base64 -d | inspect_cert
 ```
 
-Additionally, the `linkerd-identity-trust-roots` ConfigMap should now contain
-the Subject keys from both Secrets. (We can't use `inspect_cert` for this since
-there are two keys.)
+Verify that the `linkerd-identity-trust-roots` ConfigMap now contains
+the Subject keys from both Secrets.
 
 ```bash
 kubectl get configmap -n linkerd linkerd-identity-trust-roots \
         -o jsonpath='{ .data.ca-bundle\.crt }' \
-        | step certificate inspect --bundle --format json \
-        | jq -r ".[] | \"Subject: \(.extensions.subject_key_id | .[0:16])... \(.subject_dn)\""
+        | inspect_cert
 ```
 
 Note that mTLS communication is still working fine at this point. All the
@@ -858,7 +832,25 @@ proxies in the data plane are still using the old identity issuer, signed by the
 old trust anchor, and that trust anchor is still present in
 `linkerd-identity-trust-roots`.
 
-#### 2. Triggering identity issuer rotation
+#### 2. Restart the control plane
+
+Restart the control plane with `kubectl rollout restart`:
+
+```bash
+kubectl rollout restart -n linkerd deploy
+kubectl rollout status -n linkerd deploy
+```
+
+This will cause the control plane to pick up the new trust anchor bundle.
+
+#### 3. Restart the data plane
+
+At this point, you'll need to restart your workloads as well, to force the
+proxies to have the new trust anchor bundle. The exact mechanism to do this
+will depend on your workloads, but it's often just `kubectl rollout restart` for
+each of your application namespaces.
+
+#### 4. Triggering identity issuer rotation
 
 Everything is still using the old identity issuer because, strangely, manually
 triggering cert-manager to rotate the trust anchor does not automatically rotate
@@ -887,9 +879,9 @@ kubectl get secret -n linkerd linkerd-identity-issuer \
     | base64 -d | inspect_cert
 ```
 
-#### 3. Restart the control plane
+#### 5. Restart the control plane
 
-Restart the control plane with `kubectl rollout restart`:
+Restart the control plane again with `kubectl rollout restart`:
 
 ```bash
 kubectl rollout restart -n linkerd deploy
@@ -899,14 +891,14 @@ kubectl rollout status -n linkerd deploy
 This will cause the control plane to pick up the new trust anchor and identity
 issuer.
 
-#### 4. Restart the data plane
+#### 6. Restart the data plane
 
-At this point, you'll need to restart your workloads as well, to force the
-proxies to switch to the new identity issuer. The exact mechanism to do this
-when depend on your workloads, but it's often just `kubectl rollout restart` for
-each of your application namespaces.
+Again, you'll need to restart your workloads, to force the
+proxies to switch to the new identity issuer signed by the new trust anchor.
+The exact mechanism to do this will depend on your workloads, but it's often
+just `kubectl rollout restart` for each of your application namespaces.
 
-#### 5. Remove the old anchor from the trust bundle
+#### 7. Remove the old anchor from the trust bundle
 
 One last step: once everything is restarted, you'll need to remove the old trust
 anchor from the trust bundle. To do this, just copy the `linkerd-trust-anchor`
@@ -933,14 +925,15 @@ You can doublecheck this with `kubectl` again:
 ```bash
 kubectl get configmap -n linkerd linkerd-identity-trust-roots \
         -o jsonpath='{ .data.ca-bundle\.crt }' \
-        | step certificate inspect --format json \
-        | jq -r "\"Subject: \(.extensions.subject_key_id | .[0:16])... \(.subject_dn)\""
+        | inspect_cert
 ```
 
 and you should only see the single ID of the current trust anchor.
 
 At this point rotation is complete: everything is using the new trust anchor,
-and the old trust anchor is no longer trusted.
+and the old trust anchor is no longer trusted. You will need to restart your
+workloads one more time so that they are aware of only the one trust anchor
+that's still in use.
 
 ## See also