openshift · agantony · May 27, 2026
diff --git a/configuration/reissue-internal-certificates.adoc b/configuration/reissue-internal-certificates.adoc
@@ -40,18 +40,10 @@ include::modules/reissuing-internal-certificates-for-scanner-v4.adoc[leveloffset
 //Restarting the Scanner V4 containers
 include::modules/restarting-the-scanner-v4-containers.adoc[leveloffset=+3]
 
-[id="reissue-internal-certificates-secured-clusters_{context}"]
-== Reissuing internal certificates for secured clusters
-Secured clusters contain the Collector, Sensor, Admission Control, and local Scanner components.
-These components communicate with each other, and with Central by using certificates.
+//Reissuing internal certificates for secured clusters
+include::modules/reissuing-internal-certificates-secured-clusters-overview.adoc[leveloffset=+1]
 
-Choose the appropriate method to reissue the internal certificates:
-
-* Use the automatic certificate renewal feature. This is the recommended method for Operator and Helm deployments. It is the only supported method for installations if you used a cluster registration secret (CRS) to set up communication between Central and secured clusters.
-* Generate, download, and install an init bundle on the secured cluster. You must have the `Admin` user role to generate an init bundle. This method is only recommended for Operator and Helm deployments if the certificates have already expired and the secured cluster can no longer connect to Central.
-* Use the automatic upgrades feature, which is only available for static manifest deployments by using the `roxctl` CLI. This method is only recommended if you have a specific installation requirement that necessitates the use of this method.
-
-//automatic certificate renewal
+//Reissuing internal certificates for secured clusters by using automatic certificate renewal
 include::modules/reissuing-internal-certificates-for-secured-clusters-by-using-automatic-certificate-renewal.adoc[leveloffset=+2]
 
 //Verifying the status of automatic certificate renewal
@@ -60,7 +52,7 @@ include::modules/verifying-the-status-of-automatic-certificate-renewal.adoc[leve
 //Applying the latest internal certificates
 include::modules/applying-the-latest-internal-certificates.adoc[leveloffset=+3]
 
-//create and install an init bundle
+//Reissuing internal certificates for secured clusters by using init bundles
 include::modules/reissue-internal-certificates-secured-clusters.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
@@ -69,15 +61,10 @@ include::modules/reissue-internal-certificates-secured-clusters.adoc[leveloffset
 * xref:../installing/installing_ocp/init-bundle-ocp.adoc#init-bundle-ocp[Generating and applying a cluster registration secret or an init bundle for RHACS on Red Hat OpenShift]
 * xref:../installing/installing_other/init-bundle-other.adoc#init-bundle-other[Generating and applying a cluster registration secret or an init bundle for RHACS on other platforms]
 
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../installing/installing_ocp/init-bundle-ocp.adoc#init-bundle-ocp[Generating and applying a cluster registration secret or an init bundle for RHACS on Red Hat OpenShift]
-* xref:../installing/installing_other/init-bundle-other.adoc#init-bundle-other[Generating and applying a cluster registration secret or an init bundle for RHACS on other platforms]
-
-//reissue internal certificates for secured clusters by using automatic upgrades
+//Reissuing internal certificates for secured clusters by using automatic upgrades
 include::modules/reissue-internal-certificates-secured-clusters-automatic-upgrades.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
+
 * xref:../installing/installing_ocp/install-central-ocp.adoc#install-using-roxctl-ocp[Install Central using the roxctl CLI]
diff --git a/modules/applying-the-latest-internal-certificates.adoc b/modules/applying-the-latest-internal-certificates.adoc
@@ -6,6 +6,7 @@
 [id="applying-the-latest-internal-certificates_{context}"]
 = Applying the latest internal certificates
 
+[role="_abstract"]
 By manually restarting the pods of the affected cluster, you can apply the latest certificates and prevent downtime.
 
 [NOTE]

diff --git a/modules/reissue-internal-certificates-secured-clusters-automatic-upgrades.adoc b/modules/reissue-internal-certificates-secured-clusters-automatic-upgrades.adoc
@@ -6,14 +6,13 @@
 [id="reissue-internal-certificates-secured-clusters-automatic-upgrade_{context}"]
 = Reissuing internal certificates for secured clusters by using automatic upgrades
 
+[role="_abstract"]
 Secured clusters contain the Collector, Sensor, Admission Control, and local Scanner components.
 You can reissue internal certificates for these components by using automatic upgrades.
 
 [IMPORTANT]
 ====
-Automatic upgrades are only applicable to static manifest-based deployments by using the `roxctl` CLI. 
-
-For more information, see "Install Central using the roxctl CLI".
+Automatic upgrades are only applicable to static manifest-based deployments by using the `roxctl` CLI.
 ====
 
 .Prerequisites

diff --git a/modules/reissue-internal-certificates-secured-clusters.adoc b/modules/reissue-internal-certificates-secured-clusters.adoc
@@ -6,13 +6,14 @@
 [id="reissue-internal-certificates-secured-cluster_{context}"]
 = Reissuing internal certificates for secured clusters by using init bundles
 
+[role="_abstract"]
 Secured clusters contain the Collector, Sensor, Admission Control, and local Scanner components. These components use a built-in server certificate for authentication when communicating with other {rh-rhacs-first} components.
 
 The {product-title-short} portal shows an information banner when the Central certificate is about to expire.
 
 [NOTE]
 ====
-The information banner only appears 15 days before the certificate expiry date.
+The information banner is only displayed 15 days before the certificate expiry date.
 ====
 
 .Prerequisites
@@ -22,10 +23,10 @@ The information banner only appears 15 days before the certificate expiry date.
 
 [IMPORTANT]
 ====
-Store the init bundle securely because it contains secrets.
+Store the init bundle securely because it has secrets.
 You can use the same bundle to set up more than one secured cluster.
 ====
 
 .Procedure
 
-. Generate an init bundle by using the {product-title-short} portal or by using the `roxctl CLI`, and then apply the bundle to the secured cluster. For more information, see "Generating and applying a cluster registration secret or an init bundle for RHACS on Red Hat OpenShift" or "Generating and applying a cluster registration secret or an init bundle for RHACS on other platforms".
+. Generate an init bundle by using the {product-title-short} portal or by using the `roxctl CLI`, and then apply the bundle to the secured cluster.
diff --git a/modules/reissuing-internal-certificates-for-central-db.adoc b/modules/reissuing-internal-certificates-for-central-db.adoc
@@ -6,6 +6,7 @@
 [id="reissuing-internal-certificates-for-central-db_{context}"]
 = Reissuing internal certificates for Central DB
 
+[role="_abstract"]
 You can maintain a secure communication between Central DB and other {rh-rhacs-first} components by reissuing the internal certificates.
 
 .Prerequisites

diff --git a/modules/reissuing-internal-certificates-for-central-services.adoc b/modules/reissuing-internal-certificates-for-central-services.adoc
@@ -6,14 +6,15 @@
 [id="reissuing-internal-certificates-for-central-services_{context}"]
 = Reissuing internal certificates for Central services
 
+[role="_abstract"]
 The Central services contain the Central, Central DB, Scanner, and Scanner V4 components.
 The Central services use a built-in server certificate for authentication when communicating with other {rh-rhacs-first} services.
 This certificate is unique to your Central service installation.
 The {product-title-short} portal shows an informational banner when a Central service certificate is about to expire.
 
 [NOTE]
 ====
-The informational banner only appears 15 days before the certificate expiration date.
+The informational banner is only displayed 15 days before the certificate expiration date.
 ====
 
 Beginning with {product-title-short} 4.3.4, the Operator automatically rotates the service transport layer security (TLS) certificates for all of the Central components 6 months before they expire.

diff --git a/modules/reissuing-internal-certificates-for-central.adoc b/modules/reissuing-internal-certificates-for-central.adoc
@@ -6,6 +6,7 @@
 [id="reissue-internal-certificates-central_{context}"]
 = Reissuing internal certificates for Central
 
+[role="_abstract"]
 You can maintain a secure communication between Central and other {rh-rhacs-first} components by reissuing the internal certificates.
 
 .Prerequisites

diff --git a/modules/reissuing-internal-certificates-for-scanner-v4.adoc b/modules/reissuing-internal-certificates-for-scanner-v4.adoc
@@ -6,6 +6,7 @@
 [id="reissuing-internal-certificates-for-scanner-v4_{context}"]
 = Reissuing internal certificates for Scanner V4
 
+[role="_abstract"]
 You can maintain a secure communication between Scanner V4 and other {rh-rhacs-first} components by reissuing the internal certificates.
 
 .Prerequisites

diff --git a/modules/reissuing-internal-certificates-for-scanner.adoc b/modules/reissuing-internal-certificates-for-scanner.adoc
@@ -6,6 +6,7 @@
 [id="reissue-internal-certificates-scanner_{context}"]
 = Reissuing internal certificates for Scanner
 
+[role="_abstract"]
 You can maintain a secure communication between Scanner and other {rh-rhacs-first} components by reissuing the internal certificates.
 
 .Prerequisites

diff --git a/...l-certificates-for-secured-clusters-by-using-automatic-certificate-renewal.adoc b/...l-certificates-for-secured-clusters-by-using-automatic-certificate-renewal.adoc
@@ -6,6 +6,7 @@
 [id="reissuing-internal-certificates-for-secured-clusters-by-using-automatic-certificate-renewal_{context}"]
 = Reissuing internal certificates for secured clusters by using automatic certificate renewal
 
+[role="_abstract"]
 Secured clusters contain the Collector, Sensor, Admission Control, and local Scanner components. You can reissue internal certificates for these components by using automatic certificate renewal.
 
 TLS certificates are automatically renewed several months in advance but are only loaded when {product-title-short} pods restart, for example, during an upgrade.
diff --git a/modules/reissuing-internal-certificates-secured-clusters-overview.adoc b/modules/reissuing-internal-certificates-secured-clusters-overview.adoc
@@ -0,0 +1,17 @@
+// Module included in the following assemblies:
+//
+// * configuration/reissue-internal-certificates.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="reissue-internal-certificates-secured-clusters_{context}"]
+= Reissuing internal certificates for secured clusters
+
+[role="_abstract"]
+Secured clusters contain the Collector, Sensor, Admission Control, and local Scanner components.
+These components communicate with each other, and with Central by using certificates.
+
+Choose the appropriate method to reissue the internal certificates:
+
+* Use the automatic certificate renewal feature. This is the recommended method for Operator and Helm deployments. It is the only supported method for installations if you used a cluster registration secret (CRS) to set up communication between Central and secured clusters.
+* Generate, download, and install an init bundle on the secured cluster. You must have the `Admin` user role to generate an init bundle. This method is only recommended for Operator and Helm deployments if the certificates have already expired and the secured cluster can no longer connect to Central.
+* Use the automatic upgrades feature, which is only available for static manifest deployments by using the `roxctl` CLI. This method is only recommended if you have a specific installation requirement that necessitates the use of this method.
diff --git a/modules/verifying-the-status-of-automatic-certificate-renewal.adoc b/modules/verifying-the-status-of-automatic-certificate-renewal.adoc
@@ -6,13 +6,14 @@
 [id="verifying-the-status-of-automatic-certificate-renewal_{context}"]
 = Verifying the status of automatic certificate renewal
 
+[role="_abstract"]
 By viewing the *Clusters* page, you can verify that the automatic certificate renewal is active. 
 
 .Procedure
 
 . In the {product-title-short} portal, click *Platform Configuration* -> *Clusters*.
-. Verify that *Auto-refresh enabled* appears in the *Credential Expiration* column.
-
+. Verify that *Auto-refresh enabled* is displayed in the *Credential Expiration* column.
++
 [IMPORTANT]
 ====
 If a secured cluster displays a warning about soon-to-expire credentials even though auto-refresh is enabled, you must manually restart the pods of the affected cluster to apply the latest certificates and prevent downtime.