diff --git a/docs/pages/admin-guides/management/operations/ca-rotation.mdx b/docs/pages/admin-guides/management/operations/ca-rotation.mdx
index 5a0a9888ecf9c..548552f5948d1 100644
--- a/docs/pages/admin-guides/management/operations/ca-rotation.mdx
+++ b/docs/pages/admin-guides/management/operations/ca-rotation.mdx
@@ -32,8 +32,8 @@ following order:
connections from clients should reload their identity and start serving
certificates issed by the new CA, but still accept certificates issued by the
original CA.
- When rotating the [`host` CA], this automatically applies for teleport
- cluster components (Agents, Auth Service, and Proxy Service instances).
+ When rotating the [`host` CA], this automatically applies for Teleport
+ cluster components (Agents, Auth Service and Proxy Service instances).
1. `standby`: No rotation in progress. All operations have completed.
Before the final `standby` phase, you can also put the rotation in the
@@ -125,12 +125,9 @@ Service instances have completed the transition to target phase before
proceeding to the next phase. We will explain the phases in [Step
2](#step-24-start-a-manual-rotation).
-
Any OpenSSH hosts must be issued new host certificates during the
`update_servers` phase of the `host` CA rotation.
-
-
If you are joining Teleport processes to a cluster via the Teleport Auth
Service, each Teleport process needs a CA pin to trust the Auth Service.
Teleport Agents connecting to a Proxy Service address never need a CA pin, but
@@ -138,7 +135,6 @@ new Proxy Services should always use a CA pin when joining the cluster.
During the CA rotation, `tctl status` will report that there are 2 CA pins.
The CA pin configuration can accept a list including both pins.
After the rotation is complete, only the new CA pin will be reported.
-
### `user`
@@ -174,11 +170,17 @@ Teleport Database Service to trust the CA.
#### Rotating the database CAs
-
These steps provide instructions to rotate both the `db` and `db_client` CAs
together, but it is also possible to rotate just one or the other and follow the
same steps.
-
+
+Start by rotating both the `db` and `db_client` CAs to the `init` phase.
+During the `init` phase, `tctl auth sign` will issue database server
+certificates signed by the new `db` CA keys, and will output a CAs file
+including both the old and new `db_client` CA certificates.
+To avoid losing access to your self-hosted databases at any point, you should
+reconfigure your databases during the `init` phase with new certificates and
+trusted CAs.
`tctl auth sign --format db` is an exception to the usual behavior of the `init`
@@ -191,14 +193,6 @@ new `db` CA and start trusting the new `db_client` CA, and second during the
`standby` phase to stop trusting the old `db_client` CA.
-Start by rotating both the `db` and `db_client` CAs to the `init` phase.
-During the `init` phase, `tctl auth sign` will issue database server
-certificates signed by the new `db` CA keys, and will output a CAs file
-including both the old and new `db_client` CA certificates.
-To avoid losing access to your self-hosted databases at any point, you should
-reconfigure your databases during the `init` phase with new certificates and
-trusted CAs.
-
Consult the appropriate
[documentation](../../../enroll-resources/database-access/database-access.mdx)
for configuring your databases before proceeding to the `update_clients`
@@ -405,7 +399,7 @@ trust certificates signed by the original CA.
### `update_servers`
Initiate the `update_servers` phase. In this phase, Teleport cluster components
-(Agents, Auth Service, and Proxy Service instances) reload and start serving TLS
+(Agents, Auth Service and Proxy Service instances) reload and start serving TLS
and SSH certificates signed by the new certificate authority, but still accept
certificates issued by the original certificate authority. This phase only
affects the `host` CA.