diff --git a/docs/security/configuration/generate-certificates.md b/docs/security/configuration/generate-certificates.md
index f1b4719f..190f4be5 100755
--- a/docs/security/configuration/generate-certificates.md
+++ b/docs/security/configuration/generate-certificates.md
@@ -89,7 +89,7 @@ Just like the root certificate, use the `-days` option to specify an expiration
 
 Follow the steps in [Generate an admin certificate](#generate-an-admin-certificate) with new file names to generate a new certificate for each node and as many client certificates as you need. Each certificate should use its own private key.
 
-If you generate node certificates and have `opensearch_security.ssl.transport.enforce_hostname_verification` set to `true` (default), be sure to specify a common name (CN) for the certificate that matches the hostname of the intended node. If you want to use the same node certificate on all nodes (not recommended), set the hostname verification to `false`. For more information, see [Configure TLS certificates](../tls/#advanced-hostname-verification-and-dns-lookup).
+If you generate node certificates and have `opensearch_security.ssl.transport.enforce_hostname_verification` set to `true` (default), be sure to specify a common name (CN) for the certificate that matches the hostname of the intended node. If you want to use the same node certificate on all nodes (not recommended), set hostname verification to `false`. For more information, see [Configure TLS certificates](../tls/#advanced-hostname-verification-and-dns-lookup).
 
 
 ### Sample script
diff --git a/docs/security/configuration/ldap.md b/docs/security/configuration/ldap.md
index 6ad503e1..c73a1c37 100755
--- a/docs/security/configuration/ldap.md
+++ b/docs/security/configuration/ldap.md
@@ -357,7 +357,7 @@ authz:
       ...
 ```
 
-Authorization is the process of retrieving backend roles for an authenticated user from an LDAP server. This is typically the same servers that you use for authentication, but you can also use a different server. The only requirement is that the user to fetch the roles for actually exists on the LDAP server.
+Authorization is the process of retrieving backend roles for an authenticated user from an LDAP server. This is typically the same servers that you use for authentication, but you can also use a different server. The only requirement is that the user you use to fetch the roles actually exists on the LDAP server.
 
 Because the security plugin always checks if a user exists in the LDAP server, you must also configure `userbase`, `usersearch` and `username_attribute` in the `authz` section.
 
@@ -443,7 +443,7 @@ Example:
 
 ```yml
 authz:
-  ldap:  
+  ldap:
     http_enabled: true
     transport_enabled: true
     authorization_backend:
diff --git a/docs/security/configuration/security-admin.md b/docs/security/configuration/security-admin.md
index f1f36d78..d692ac0c 100755
--- a/docs/security/configuration/security-admin.md
+++ b/docs/security/configuration/security-admin.md
@@ -17,7 +17,7 @@ After the `.opensearch_security` index is initialized, you can use OpenSearch Da
 
 ## Configure the admin certificate
 
-You can configure all certificates that should have admin privileges in `opensearch.yml` stating their respective distinguished names (DNs). If you use the demo certificates, for example, you can use the `kirk` certificate:
+You can configure all certificates that should have admin privileges in `opensearch.yml` by specifying respective distinguished names (DNs). If you use the demo certificates, for example, you can use the `kirk` certificate:
 
 ```yml
 opensearch_security.authcz.admin_dn:
diff --git a/docs/security/configuration/tls.md b/docs/security/configuration/tls.md
index e9b6503c..cd6c211e 100755
--- a/docs/security/configuration/tls.md
+++ b/docs/security/configuration/tls.md
@@ -85,7 +85,7 @@ opensearch_security.nodes_dn:
   - '/CN=.*regex/'
 ```
 
-If your node certificates have an OID identifier in the SAN section, you can omit this configuration.
+If your node certificates have an Object ID (OID) identifier in the SAN section, you can omit this configuration.
 
 
 ## Configure admin certificates
@@ -175,12 +175,12 @@ You can limit the allowed ciphers and TLS protocols for the REST layer. For exam
 
 If this setting is not enabled, the ciphers and TLS versions are negotiated between the browser and the security plugin automatically, which in some cases can lead to a weaker cipher suite being used. You can configure the ciphers and protocols using the following settings.
 
-Name | Description
-:--- | :---
-`opensearch_security.ssl.http.enabled_ciphers` | Array, enabled TLS cipher suites for the REST layer. Only Java format is supported.
-`opensearch_security.ssl.http.enabled_protocols` | Array, enabled TLS protocols for the REST layer. Only Java format is supported.
-`opensearch_security.ssl.transport.enabled_ciphers` | Array, enabled TLS cipher suites for the transport layer. Only Java format is supported.
-`opensearch_security.ssl.transport.enabled_protocols` | Array, enabled TLS protocols for the transport layer. Only Java format is supported.
+Name | Data Type | Description
+:--- | :--- | :---
+`opensearch_security.ssl.http.enabled_ciphers` | Array | Enabled TLS cipher suites for the REST layer. Only Java format is supported.
+`opensearch_security.ssl.http.enabled_protocols` | Array | Enabled TLS protocols for the REST layer. Only Java format is supported.
+`opensearch_security.ssl.transport.enabled_ciphers` | Array | Enabled TLS cipher suites for the transport layer. Only Java format is supported.
+`opensearch_security.ssl.transport.enabled_protocols` | Array | Enabled TLS protocols for the transport layer. Only Java format is supported.
 
 ### Example settings