diff --git a/serverlessworkflow/modules/ROOT/pages/cloud/operator/add-custom-ca-to-a-workflow-pod.adoc b/serverlessworkflow/modules/ROOT/pages/cloud/operator/add-custom-ca-to-a-workflow-pod.adoc
index b91b61d7e..3ecf06630 100644
--- a/serverlessworkflow/modules/ROOT/pages/cloud/operator/add-custom-ca-to-a-workflow-pod.adoc
+++ b/serverlessworkflow/modules/ROOT/pages/cloud/operator/add-custom-ca-to-a-workflow-pod.adoc
@@ -12,7 +12,7 @@ If you're working with containers running Java applications and need to add a CA
 
 If you have a containerized Java application that connects to an SSL endpoint with a certificate signed by an internal authority (like SSL terminated routes on a cluster) you need to make sure Java can read the CA Authority certificate and verify it. Java unfortunately doesn't load certificates directly, but rather store them in a {keytool-docs}[keystore].
 
-The default trust store under `$JAVA_HOME/lib/security/cacerts` contains only CA's which are shipped with the Java distribution and there's the `keytool` tool that knows how to manipulate those key stores.
+The default trust store under `$JAVA_HOME/lib/security/cacerts` contains only CA's that are shipped with the Java distribution and there is the `keytool` tool that knows how to manipulate those key stores.
 The containerized application may not know the CA certificate in build time, and so we need to add it to the trust-store in deployment. To automate that we can use a combination of an init-container and a shared directory to pass the mutated trust store to the container before it runs. Let's run this step by step:
 
 === Step 1: Obtain the CA Certificate