diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
index c828237de1..f3470473bf 100644
--- 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).
PKCS #8, PKCS #1 syntax
@@ -222,9 +223,9 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
- - 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
index c828237de1..f3470473bf 100644
--- 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).
PKCS #8, PKCS #1 syntax
@@ -222,9 +223,9 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
- - 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: