TELCODOCS-2699 DITA migration cleanup for troubleshooting-cert-maintenance.adoc

modules/troubleshooting-certs-auto-etcd.adoc

@@ -6,6 +6,7 @@
 [id="troubleshooting-certs-auto-etcd_{context}"]
 = Certificates managed by etcd
 
+[role="_abstract"]
 The etcd certificates are used for encrypted communication between etcd member peers as well as encrypted client traffic. 
 The certificates are renewed automatically within the cluster provided that communication between all nodes and all services is current.
 Therefore, if your cluster might lose communication between components during a specific period of time, which is close to the end of the etcd certificate lifetime, it is recommended to renew the certificate in advance.

modules/troubleshooting-certs-auto-node.adoc

@@ -6,6 +6,7 @@
 [id="troubleshooting-certs-auto-node_{context}"]
 = Node certificates
 
+[role="_abstract"]
 Node certificates are self-signed certificates, which means that they are signed by the cluster and they originate from an internal certificate authority (CA) that is generated by the bootstrap process.
 
 After the cluster is installed, the cluster automatically renews the node certificates.

modules/troubleshooting-certs-auto-service-ca.adoc

@@ -6,6 +6,7 @@
 [id="troubleshooting-certs-auto-service-ca_{context}"]
 = Service CA certificates
 
+[role="_abstract"]
 The `service-ca` is an Operator that creates a self-signed certificate authority (CA) when an {product-title} cluster is deployed.
 This allows user to add certificates to their deployments without manually creating them. 
 Service CA certificates are self-signed certificates.

modules/troubleshooting-certs-auto.adoc

@@ -6,6 +6,7 @@
 [id="troubleshooting-certs-auto_{context}"]
 = Certificates managed by the cluster
 
+[role="_abstract"]
 You only need to check cluster-managed certificates if you detect an issue in the logs.
 The following certificates are automatically managed by the cluster:
 

modules/troubleshooting-certs-manual-proxy.adoc

@@ -6,6 +6,7 @@
 [id="troubleshooting-certs-manual-proxy_{context}"]
 = Managing proxy certificates
 
+[role="_abstract"]
 Proxy certificates allow users to specify one or more custom certificate authority (CA) certificates that are used by platform components when making egress connections.
 
 [NOTE]
@@ -25,5 +26,5 @@ Therefore, you need to pull the certificate from the `ConfigMap` object of your
 ----
 $ openssl x509 -enddate -noout -in <cert_file_name>.pem
 ----
-
-For more information about determining how and when to renew your proxy certificates, see "Proxy certificates" in _Security and compliance_.
++
+For more information about determining how and when to renew your proxy certificates, see "Proxy certificates" in _Security and compliance_.

modules/troubleshooting-certs-manual-user-provisioned.adoc

@@ -6,6 +6,7 @@
 [id="troubleshooting-certs-manual-user-provisioned_{context}"]
 = User-provisioned API server certificates
 
+[role="_abstract"]
 The API server is accessible by clients that are external to the cluster at `api.<cluster_name>.<base_domain>`.
 You might want clients to access the API server at a different hostname or without the need to distribute the cluster-managed certificate authority (CA) certificates to the clients.
 You must set a custom default certificate to be used by the API server when serving content.

modules/troubleshooting-certs-manual.adoc

@@ -6,6 +6,7 @@
 [id="troubleshooting-certs-manual_{context}"]
 = Certificates manually managed by the administrator
 
+[role="_abstract"]
 The following certificates must be renewed by a cluster administrator:
 
 * Proxy certificates