From 7b498b53ca7acbec0e195980a7aa7f2ee33fa955 Mon Sep 17 00:00:00 2001 From: Phil Henderson Date: Tue, 16 Dec 2025 13:40:05 -0600 Subject: [PATCH 1/5] Update trust anchor rotation instructions Signed-off-by: Phil Henderson --- ...-rotating-control-plane-tls-credentials.md | 88 +++++++++++++------ ...-rotating-control-plane-tls-credentials.md | 88 +++++++++++++------ ...-rotating-control-plane-tls-credentials.md | 88 +++++++++++++------ ...-rotating-control-plane-tls-credentials.md | 88 +++++++++++++------ ...-rotating-control-plane-tls-credentials.md | 88 +++++++++++++------ ...-rotating-control-plane-tls-credentials.md | 88 +++++++++++++------ ...-rotating-control-plane-tls-credentials.md | 88 +++++++++++++------ 7 files changed, 420 insertions(+), 196 deletions(-) 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..bcbdeac96e 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 @@ -609,11 +609,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 +639,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 +710,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 +806,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 +814,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 +858,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 should now contain +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 +872,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 +when 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,7 +919,7 @@ 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`: @@ -899,14 +931,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 that uses the trust anchor bundle. +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. -#### 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 +965,14 @@ 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 again so they only are aware of the one trust anchor. ## 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..bcbdeac96e 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 @@ -609,11 +609,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 +639,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 +710,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 +806,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 +814,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 +858,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 should now contain +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 +872,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 +when 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,7 +919,7 @@ 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`: @@ -899,14 +931,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 that uses the trust anchor bundle. +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. -#### 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 +965,14 @@ 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 again so they only are aware of the one trust anchor. ## 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..bcbdeac96e 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 @@ -609,11 +609,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 +639,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 +710,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 +806,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 +814,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 +858,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 should now contain +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 +872,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 +when 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,7 +919,7 @@ 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`: @@ -899,14 +931,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 that uses the trust anchor bundle. +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. -#### 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 +965,14 @@ 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 again so they only are aware of the one trust anchor. ## 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..bcbdeac96e 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 @@ -609,11 +609,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 +639,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 +710,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 +806,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 +814,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 +858,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 should now contain +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 +872,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 +when 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,7 +919,7 @@ 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`: @@ -899,14 +931,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 that uses the trust anchor bundle. +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. -#### 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 +965,14 @@ 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 again so they only are aware of the one trust anchor. ## 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..bcbdeac96e 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 @@ -609,11 +609,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 +639,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 +710,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 +806,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 +814,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 +858,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 should now contain +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 +872,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 +when 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,7 +919,7 @@ 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`: @@ -899,14 +931,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 that uses the trust anchor bundle. +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. -#### 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 +965,14 @@ 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 again so they only are aware of the one trust anchor. ## 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..bcbdeac96e 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 @@ -609,11 +609,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 +639,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 +710,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 +806,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 +814,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 +858,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 should now contain +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 +872,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 +when 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,7 +919,7 @@ 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`: @@ -899,14 +931,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 that uses the trust anchor bundle. +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. -#### 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 +965,14 @@ 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 again so they only are aware of the one trust anchor. ## 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..bcbdeac96e 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 @@ -609,11 +609,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 +639,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 +710,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 +806,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 +814,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 +858,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 should now contain +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 +872,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 +when 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,7 +919,7 @@ 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`: @@ -899,14 +931,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 that uses the trust anchor bundle. +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. -#### 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 +965,14 @@ 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 again so they only are aware of the one trust anchor. ## See also From e6a12138f143bacb3dfcfb8d209e85624ea7ae13 Mon Sep 17 00:00:00 2001 From: Phil Henderson Date: Tue, 16 Dec 2025 14:30:16 -0600 Subject: [PATCH 2/5] Remove unneeded cert-manager RBAC setup Signed-off-by: Phil Henderson --- ...-rotating-control-plane-tls-credentials.md | 40 ------------------- ...-rotating-control-plane-tls-credentials.md | 40 ------------------- ...-rotating-control-plane-tls-credentials.md | 40 ------------------- ...-rotating-control-plane-tls-credentials.md | 40 ------------------- ...-rotating-control-plane-tls-credentials.md | 40 ------------------- ...-rotating-control-plane-tls-credentials.md | 40 ------------------- ...-rotating-control-plane-tls-credentials.md | 40 ------------------- 7 files changed, 280 deletions(-) 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 bcbdeac96e..9648c8dbbf 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 - < Date: Tue, 16 Dec 2025 14:37:00 -0600 Subject: [PATCH 3/5] Updated based on PR feedback Signed-off-by: Phil Henderson --- ...tically-rotating-control-plane-tls-credentials.md | 12 ++++++------ ...tically-rotating-control-plane-tls-credentials.md | 12 ++++++------ ...tically-rotating-control-plane-tls-credentials.md | 12 ++++++------ ...tically-rotating-control-plane-tls-credentials.md | 12 ++++++------ ...tically-rotating-control-plane-tls-credentials.md | 12 ++++++------ ...tically-rotating-control-plane-tls-credentials.md | 12 ++++++------ ...tically-rotating-control-plane-tls-credentials.md | 12 ++++++------ 7 files changed, 42 insertions(+), 42 deletions(-) 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 9648c8dbbf..3f99d16f0d 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 @@ -818,7 +818,7 @@ kubectl get secret -n cert-manager linkerd-previous-anchor \ | base64 -d | inspect_cert ``` -Verify that the `linkerd-identity-trust-roots` ConfigMap should now contain +Verify that the `linkerd-identity-trust-roots` ConfigMap now contains the Subject keys from both Secrets. ```bash @@ -847,7 +847,7 @@ This will cause the control plane to pick up the new trust anchor bundle. 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 -when depend on your workloads, but it's often just `kubectl rollout restart` for +will depend on your workloads, but it's often just `kubectl rollout restart` for each of your application namespaces. #### 4. Triggering identity issuer rotation @@ -881,7 +881,7 @@ kubectl get secret -n linkerd linkerd-identity-issuer \ #### 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 @@ -894,8 +894,8 @@ issuer. #### 6. Restart the data plane Again, you'll need to restart your workloads, to force the -proxies to switch to the new identity issuer that uses the trust anchor bundle. -The exact mechanism to do this when depend on your workloads, but it's often +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. #### 7. Remove the old anchor from the trust bundle @@ -932,7 +932,7 @@ 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. You will need to restart your -workloads again so they only are aware of the one trust anchor. +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 9648c8dbbf..3f99d16f0d 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 @@ -818,7 +818,7 @@ kubectl get secret -n cert-manager linkerd-previous-anchor \ | base64 -d | inspect_cert ``` -Verify that the `linkerd-identity-trust-roots` ConfigMap should now contain +Verify that the `linkerd-identity-trust-roots` ConfigMap now contains the Subject keys from both Secrets. ```bash @@ -847,7 +847,7 @@ This will cause the control plane to pick up the new trust anchor bundle. 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 -when depend on your workloads, but it's often just `kubectl rollout restart` for +will depend on your workloads, but it's often just `kubectl rollout restart` for each of your application namespaces. #### 4. Triggering identity issuer rotation @@ -881,7 +881,7 @@ kubectl get secret -n linkerd linkerd-identity-issuer \ #### 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 @@ -894,8 +894,8 @@ issuer. #### 6. Restart the data plane Again, you'll need to restart your workloads, to force the -proxies to switch to the new identity issuer that uses the trust anchor bundle. -The exact mechanism to do this when depend on your workloads, but it's often +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. #### 7. Remove the old anchor from the trust bundle @@ -932,7 +932,7 @@ 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. You will need to restart your -workloads again so they only are aware of the one trust anchor. +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 9648c8dbbf..3f99d16f0d 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 @@ -818,7 +818,7 @@ kubectl get secret -n cert-manager linkerd-previous-anchor \ | base64 -d | inspect_cert ``` -Verify that the `linkerd-identity-trust-roots` ConfigMap should now contain +Verify that the `linkerd-identity-trust-roots` ConfigMap now contains the Subject keys from both Secrets. ```bash @@ -847,7 +847,7 @@ This will cause the control plane to pick up the new trust anchor bundle. 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 -when depend on your workloads, but it's often just `kubectl rollout restart` for +will depend on your workloads, but it's often just `kubectl rollout restart` for each of your application namespaces. #### 4. Triggering identity issuer rotation @@ -881,7 +881,7 @@ kubectl get secret -n linkerd linkerd-identity-issuer \ #### 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 @@ -894,8 +894,8 @@ issuer. #### 6. Restart the data plane Again, you'll need to restart your workloads, to force the -proxies to switch to the new identity issuer that uses the trust anchor bundle. -The exact mechanism to do this when depend on your workloads, but it's often +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. #### 7. Remove the old anchor from the trust bundle @@ -932,7 +932,7 @@ 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. You will need to restart your -workloads again so they only are aware of the one trust anchor. +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 9648c8dbbf..3f99d16f0d 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 @@ -818,7 +818,7 @@ kubectl get secret -n cert-manager linkerd-previous-anchor \ | base64 -d | inspect_cert ``` -Verify that the `linkerd-identity-trust-roots` ConfigMap should now contain +Verify that the `linkerd-identity-trust-roots` ConfigMap now contains the Subject keys from both Secrets. ```bash @@ -847,7 +847,7 @@ This will cause the control plane to pick up the new trust anchor bundle. 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 -when depend on your workloads, but it's often just `kubectl rollout restart` for +will depend on your workloads, but it's often just `kubectl rollout restart` for each of your application namespaces. #### 4. Triggering identity issuer rotation @@ -881,7 +881,7 @@ kubectl get secret -n linkerd linkerd-identity-issuer \ #### 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 @@ -894,8 +894,8 @@ issuer. #### 6. Restart the data plane Again, you'll need to restart your workloads, to force the -proxies to switch to the new identity issuer that uses the trust anchor bundle. -The exact mechanism to do this when depend on your workloads, but it's often +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. #### 7. Remove the old anchor from the trust bundle @@ -932,7 +932,7 @@ 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. You will need to restart your -workloads again so they only are aware of the one trust anchor. +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 9648c8dbbf..3f99d16f0d 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 @@ -818,7 +818,7 @@ kubectl get secret -n cert-manager linkerd-previous-anchor \ | base64 -d | inspect_cert ``` -Verify that the `linkerd-identity-trust-roots` ConfigMap should now contain +Verify that the `linkerd-identity-trust-roots` ConfigMap now contains the Subject keys from both Secrets. ```bash @@ -847,7 +847,7 @@ This will cause the control plane to pick up the new trust anchor bundle. 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 -when depend on your workloads, but it's often just `kubectl rollout restart` for +will depend on your workloads, but it's often just `kubectl rollout restart` for each of your application namespaces. #### 4. Triggering identity issuer rotation @@ -881,7 +881,7 @@ kubectl get secret -n linkerd linkerd-identity-issuer \ #### 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 @@ -894,8 +894,8 @@ issuer. #### 6. Restart the data plane Again, you'll need to restart your workloads, to force the -proxies to switch to the new identity issuer that uses the trust anchor bundle. -The exact mechanism to do this when depend on your workloads, but it's often +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. #### 7. Remove the old anchor from the trust bundle @@ -932,7 +932,7 @@ 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. You will need to restart your -workloads again so they only are aware of the one trust anchor. +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 9648c8dbbf..3f99d16f0d 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 @@ -818,7 +818,7 @@ kubectl get secret -n cert-manager linkerd-previous-anchor \ | base64 -d | inspect_cert ``` -Verify that the `linkerd-identity-trust-roots` ConfigMap should now contain +Verify that the `linkerd-identity-trust-roots` ConfigMap now contains the Subject keys from both Secrets. ```bash @@ -847,7 +847,7 @@ This will cause the control plane to pick up the new trust anchor bundle. 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 -when depend on your workloads, but it's often just `kubectl rollout restart` for +will depend on your workloads, but it's often just `kubectl rollout restart` for each of your application namespaces. #### 4. Triggering identity issuer rotation @@ -881,7 +881,7 @@ kubectl get secret -n linkerd linkerd-identity-issuer \ #### 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 @@ -894,8 +894,8 @@ issuer. #### 6. Restart the data plane Again, you'll need to restart your workloads, to force the -proxies to switch to the new identity issuer that uses the trust anchor bundle. -The exact mechanism to do this when depend on your workloads, but it's often +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. #### 7. Remove the old anchor from the trust bundle @@ -932,7 +932,7 @@ 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. You will need to restart your -workloads again so they only are aware of the one trust anchor. +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 9648c8dbbf..3f99d16f0d 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 @@ -818,7 +818,7 @@ kubectl get secret -n cert-manager linkerd-previous-anchor \ | base64 -d | inspect_cert ``` -Verify that the `linkerd-identity-trust-roots` ConfigMap should now contain +Verify that the `linkerd-identity-trust-roots` ConfigMap now contains the Subject keys from both Secrets. ```bash @@ -847,7 +847,7 @@ This will cause the control plane to pick up the new trust anchor bundle. 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 -when depend on your workloads, but it's often just `kubectl rollout restart` for +will depend on your workloads, but it's often just `kubectl rollout restart` for each of your application namespaces. #### 4. Triggering identity issuer rotation @@ -881,7 +881,7 @@ kubectl get secret -n linkerd linkerd-identity-issuer \ #### 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 @@ -894,8 +894,8 @@ issuer. #### 6. Restart the data plane Again, you'll need to restart your workloads, to force the -proxies to switch to the new identity issuer that uses the trust anchor bundle. -The exact mechanism to do this when depend on your workloads, but it's often +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. #### 7. Remove the old anchor from the trust bundle @@ -932,7 +932,7 @@ 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. You will need to restart your -workloads again so they only are aware of the one trust anchor. +workloads one more time so that they are aware of only the one trust anchor that's still in use. ## See also From 7a585a36e9beb6119ce9bedde89f491cefe455c9 Mon Sep 17 00:00:00 2001 From: Phil Henderson Date: Tue, 16 Dec 2025 15:51:29 -0600 Subject: [PATCH 4/5] Fixed lint issue Signed-Off-By: phil@buoyant.io Signed-off-by: Phil Henderson --- .../automatically-rotating-control-plane-tls-credentials.md | 3 ++- .../automatically-rotating-control-plane-tls-credentials.md | 3 ++- .../automatically-rotating-control-plane-tls-credentials.md | 3 ++- .../automatically-rotating-control-plane-tls-credentials.md | 3 ++- .../automatically-rotating-control-plane-tls-credentials.md | 3 ++- .../automatically-rotating-control-plane-tls-credentials.md | 3 ++- 6 files changed, 12 insertions(+), 6 deletions(-) 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 3f99d16f0d..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 @@ -932,7 +932,8 @@ 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. 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. +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 3f99d16f0d..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 @@ -932,7 +932,8 @@ 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. 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. +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 3f99d16f0d..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 @@ -932,7 +932,8 @@ 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. 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. +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 3f99d16f0d..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 @@ -932,7 +932,8 @@ 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. 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. +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 3f99d16f0d..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 @@ -932,7 +932,8 @@ 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. 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. +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 3f99d16f0d..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 @@ -932,7 +932,8 @@ 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. 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. +workloads one more time so that they are aware of only the one trust anchor +that's still in use. ## See also From 8b162220fee20823a897f67b10768ff4e9f39f89 Mon Sep 17 00:00:00 2001 From: Phil Henderson Date: Tue, 16 Dec 2025 16:11:09 -0600 Subject: [PATCH 5/5] Fixing edge Signed-off-by: Phil Henderson --- .../automatically-rotating-control-plane-tls-credentials.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) 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 3f99d16f0d..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 @@ -932,7 +932,8 @@ 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. 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. +workloads one more time so that they are aware of only the one trust anchor +that's still in use. ## See also