formatting and copyedits

camunda · Jul 22, 2024 · 8dbc2c2 · 8dbc2c2
1 parent 8d27b9c
commit 8dbc2c2
Show file tree

Hide file tree

Showing 2 changed files with 26 additions and 18 deletions.
diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -200,7 +200,8 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 1. Provide two [TLS secrets](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) for the Zeebe Gateway.
 
    - The first TLS secret is issued to the Zeebe Gateway Service Name. This must use the [PKCS #8 syntax](https://en.wikipedia.org/wiki/PKCS_8) or [PKCS #1 syntax](https://en.wikipedia.org/wiki/PKCS_1) as Zeebe only supports these, referenced as `camunda-platform-internal-service-certificate`.
-     In the example below, a TLS certificate is generated for the Zeebe Gateway service with an [annotation](https://docs.openshift.com/container-platform/latest/security/certificates/service-serving-certificate.html). The generated certificate will be in the form of a secret.
+
+   In the example below, a TLS certificate is generated for the Zeebe Gateway service with an [annotation](https://docs.openshift.com/container-platform/latest/security/certificates/service-serving-certificate.html). The generated certificate will be in the form of a secret.
 
    ```yaml
    zeebeGateway:
@@ -209,7 +210,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
          service.beta.openshift.io/serving-cert-secret-name: camunda-platform-internal-service-certificate
    ```
 
-   Another option would be to use [Cert Manager](https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html). For more details, review the [OpenShift documentation](https://docs.openshift.com/container-platform/latest/networking/routes/secured-routes.html#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes).
+   Another option is [Cert Manager](https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html). For more details, review the [OpenShift documentation](https://docs.openshift.com/container-platform/latest/networking/routes/secured-routes.html#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes).
 
     <details>
       <summary>PKCS #8, PKCS #1 syntax</summary>
@@ -222,9 +223,9 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 
     </details>
 
-   - The second TLS secret is used on the exposed route, referenced as `camunda-platform-external-certificate`. For example, this would be the same TLS secret you would use for Ingress.
+   - The second TLS secret is used on the exposed route, referenced as `camunda-platform-external-certificate`. For example, this would be the same TLS secret used for Ingress.
 
-2. Configure your Zeebe Gateway Ingress to create a [Re-encrypt Route](https://docs.openshift.com/container-platform/latest/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration):
+1. Configure your Zeebe Gateway Ingress to create a [Re-encrypt Route](https://docs.openshift.com/container-platform/latest/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration):
 
 ```yaml
 zeebeGateway:
@@ -331,11 +332,16 @@ tasklist:
 The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection).
 
 5. For Connectors:
+   :::note
+
+The following will no longer be required when [the Connectors component supports PKCS #1 and PKCS #8](https://github.com/camunda/connectors/issues/2806).
 
-The Connectors component will only accept a `jks` (Java KeyStore) certificate.
+:::
+
+The Connectors component only accepts a `jks` (Java KeyStore) certificate.
 If you have followed our previous recommendation of generating a TLS certificate using the OpenShift annotation, you will have a `PKCS #1` certificate the Connectors component will not accept.
 
-For convenience, below are a number of commands that will convert the `PKCS #1` certificate, generated by OpenShift to a `jks` format the Connectors component accepts:
+Below are a number of commands that convert the `PKCS #1` certificate generated by OpenShift to a `jks` format the Connectors component accepts:
 
 ```bash
 # Grab OpenShift generated TLS certificate.
@@ -356,9 +362,7 @@ Create a generic TLS secret from the `jks` file:
 kubectl create secret generic keystore -n camunda --from-file keystore.jks
 ```
 
-This workaround will not be required when [the Connectors component supports PKCS #1 and PKCS #8](https://github.com/camunda/connectors/issues/2806).
-
-Once the secret is created, the following example `values.yaml` config can be followed:
+Once the secret is created, follow the below example `values.yaml` config:
 
 ```yaml
 connectors:

diff --git a/versioned_docs/version-8.5/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.5/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -200,7 +200,8 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 1. Provide two [TLS secrets](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) for the Zeebe Gateway.
 
    - The first TLS secret is issued to the Zeebe Gateway Service Name. This must use the [PKCS #8 syntax](https://en.wikipedia.org/wiki/PKCS_8) or [PKCS #1 syntax](https://en.wikipedia.org/wiki/PKCS_1) as Zeebe only supports these, referenced as `camunda-platform-internal-service-certificate`.
-     In the example below, a TLS certificate is generated for the Zeebe Gateway service with an [annotation](https://docs.openshift.com/container-platform/latest/security/certificates/service-serving-certificate.html). The generated certificate will be in the form of a secret.
+
+   In the example below, a TLS certificate is generated for the Zeebe Gateway service with an [annotation](https://docs.openshift.com/container-platform/latest/security/certificates/service-serving-certificate.html). The generated certificate will be in the form of a secret.
 
    ```yaml
    zeebeGateway:
@@ -209,7 +210,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
          service.beta.openshift.io/serving-cert-secret-name: camunda-platform-internal-service-certificate
    ```
 
-   Another option would be to use [Cert Manager](https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html). For more details, review the [OpenShift documentation](https://docs.openshift.com/container-platform/latest/networking/routes/secured-routes.html#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes).
+   Another option is [Cert Manager](https://docs.openshift.com/container-platform/latest/security/cert_manager_operator/index.html). For more details, review the [OpenShift documentation](https://docs.openshift.com/container-platform/latest/networking/routes/secured-routes.html#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes).
 
     <details>
       <summary>PKCS #8, PKCS #1 syntax</summary>
@@ -222,9 +223,9 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 
     </details>
 
-   - The second TLS secret is used on the exposed route, referenced as `camunda-platform-external-certificate`. For example, this would be the same TLS secret you would use for Ingress.
+   - The second TLS secret is used on the exposed route, referenced as `camunda-platform-external-certificate`. For example, this would be the same TLS secret used for Ingress.
 
-2. Configure your Zeebe Gateway Ingress to create a [Re-encrypt Route](https://docs.openshift.com/container-platform/latest/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration):
+1. Configure your Zeebe Gateway Ingress to create a [Re-encrypt Route](https://docs.openshift.com/container-platform/latest/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration):
 
 ```yaml
 zeebeGateway:
@@ -331,11 +332,16 @@ tasklist:
 The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection).
 
 5. For Connectors:
+   :::note
+
+The following will no longer be required when [the Connectors component supports PKCS #1 and PKCS #8](https://github.com/camunda/connectors/issues/2806).
 
-The Connectors component will only accept a `jks` (Java KeyStore) certificate.
+:::
+
+The Connectors component only accepts a `jks` (Java KeyStore) certificate.
 If you have followed our previous recommendation of generating a TLS certificate using the OpenShift annotation, you will have a `PKCS #1` certificate the Connectors component will not accept.
 
-For convenience, below are a number of commands that will convert the `PKCS #1` certificate, generated by OpenShift to a `jks` format the Connectors component accepts:
+Below are a number of commands that convert the `PKCS #1` certificate generated by OpenShift to a `jks` format the Connectors component accepts:
 
 ```bash
 # Grab OpenShift generated TLS certificate.
@@ -356,9 +362,7 @@ Create a generic TLS secret from the `jks` file:
 kubectl create secret generic keystore -n camunda --from-file keystore.jks
 ```
 
-This workaround will not be required when [the Connectors component supports PKCS #1 and PKCS #8](https://github.com/camunda/connectors/issues/2806).
-
-Once the secret is created, the following example `values.yaml` config can be followed:
+Once the secret is created, follow the below example `values.yaml` config:
 
 ```yaml
 connectors: