diff --git a/modules/installation-guide/partials/proc_importing-untrusted-tls-certificates.adoc b/modules/installation-guide/partials/proc_importing-untrusted-tls-certificates.adoc
index 7c371ddcbc2..f52bb9b9ed5 100644
--- a/modules/installation-guide/partials/proc_importing-untrusted-tls-certificates.adoc
+++ b/modules/installation-guide/partials/proc_importing-untrusted-tls-certificates.adoc
@@ -1,17 +1,17 @@
 
 [id="importing-untrusted-tls-certificates_{context}"]
-= Importing untrusted TLS certificates to {prod-short}
+= Importing self-signed (institutional) TLS certificates to {prod-short}
 
-Internal communications between {prod-short} components are, by default, encrypted with TLS.
+External communications between {prod-short} components are, by default, encrypted with TLS.
 Communications of {prod-short} components with external services such as proxies, source code repositories, identity providers may require using of TLS.
-Those communications require the use of TLS certificates signed by trusted Certificate Authorities.
+Those communications require the use of TLS certificates signed by trusted Certificate Authorities (CA).
 
-When the certificates used by {prod-short} components or by an external service are signed by an untrusted CA it can be necessary to import the CA certificate in the {prod-short} installation, so that every {prod-short} component will consider them as signed by a trusted CA.
+When the certificates used by {prod-short} components or by an external service are signed by an institutional CA it can be necessary to import the CA certificate in the {prod-short} installation, so that every {prod-short} component will consider them as signed by a trusted CA.
 
 Typical cases that may require this addition are:
 
-* when the underlying Kubernetes cluster uses TLS certificates signed by a CA that is not trusted,
-* when {prod-short} server or workspace components connect to external services such as {identity-provider} or a Git server that use TLS certificates signed by an untrusted CA.
+* when the underlying Kubernetes/Openshift cluster uses TLS certificates signed by a CA that is not commonly trusted,
+* when {prod-short} server or workspace components connect to external services such as {identity-provider} or a Git server that use TLS certificates signed by an institutional CA.
 
 {prod-short} uses labeled ConfigMaps in {prod-short} namespace as sources for TLS certificates.
 The ConfigMaps can have arbitrary number of keys with arbitrary number of certificates each.
@@ -30,6 +30,12 @@ the cluster contains cluster-wide trusted CA certificates added through the link
 - Based on this annotation, OpenShift automatically injects the cluster-wide trusted CA certificates inside the `ca-bundle.crt` key of ConfigMap
 ====
 
+[NOTE]
+====
+Some {prod-short} components require to have full certificates chain in order to trust the endpoint.
+If the cluster is configured with an intermediate institutional certificate, then the whole chain (including self-signed root) should be added to {prod-short}.
+====
+
 == Adding new CA certificates into {prod-short}
 
 This guide can be used before the installations of {prod-short} or when {prod-short} is already installed and running.