basic security tutorial now mostly works for private/3P CA case

Author: shainaraskas

deploy-manage/security/self-tls-considerations.md

@@ -6,18 +6,18 @@ applies_to:
     eck:
 products:
   - id: elasticsearch
-navigation_title: External CA considerations
+navigation_title: Private or 3P CA considerations
 ---
 
-# Considerations for using an external CA for transport layer security
+# Considerations for using an private or third-party CA for transport layer security
 
 By default, {{es}} uses mutual TLS (mTLS) to secure node-to-node transport connections. Mutual TLS means that data is encrypted in transit, ensuring confidentiality and integrity, and also that both nodes in a connection must present a valid certificate to the other node when establishing the connection. Each node requires that certificates be issued by a trusted certificate authority, ensuring that only authorized nodes can connect. Configure trusted certificate authorities using settings in the [`xpack.security.transport.ssl.*`](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#transport-tls-ssl-settings) namespace, such as `xpack.security.transport.ssl.certificate_authorities` and `xpack.security.transport.ssl.truststore.path`. 
 
 ::::{warning}
 Transport connections between {{es}} nodes are security-critical and you must protect them carefully. Malicious actors who can observe or interfere with unencrypted node-to-node transport traffic can read or modify cluster data. A malicious actor who can establish a transport connection might be able to invoke system-internal APIs, including APIs that read or modify cluster data.
 ::::
 
-## External CA mTLS transport certificate requirements
+## mTLS transport certificate requirements for private or third-party CAs
 
 Obtain your transport certificates from a certificate authority that only issues certificates to {{es}} nodes permitted to connect to your cluster. Do not use a public certificate authority or an organization-wide private certificate authority, because these issue certificates to entities beyond your authorized cluster nodes. Use a dedicated private certificate authority for each {{es}} cluster.
 

deploy-manage/security/set-up-basic-security.md

@@ -17,34 +17,45 @@ Configuring TLS between nodes is the basic security setup to prevent unauthorize
 
 This document focuses on the **manual configuration** of TLS for [{{es}} transport protocol](./secure-cluster-communications.md#encrypt-internode-communication) in self-managed environments. Use this approach if you want to provide your own TLS certificates, generate them with Elastic’s tools, or have full control over the configuration. Alternatively, {{es}} can [automatically generate and configure HTTPS certificates](./self-auto-setup.md) for you.
 
+In this guide, you will learn how to:
+
+* [Either provide or generate security certificates](#obtain-certificates).
+* [Configure your {{es}} nodes to use the generated certificate for the transport layer](#encrypt-internode-communication).
+
+Refer to [Transport TLS/SSL settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#transport-tls-ssl-settings) for the complete list of available settings in {{es}}.
+
 ::::{note}
 For other deployment types, such as {{ech}}, {{ece}}, or {{eck}}, refer to [](./secure-cluster-communications.md).
 ::::
 
-In this guide, you will learn how to:
+## Obtain certificates
 
-* [Generate a Certificate Authority (CA) and a server certificate using the `elasticsearch-certutil` tool](#generate-certificates).
-* [Configure your {{es}} nodes to use the generated certificate for the transport layer](#encrypt-internode-communication).
+You can add as many nodes as you want in a cluster but they must be able to communicate with each other. The communication between nodes in a cluster is handled by the transport module. To secure your cluster, you must ensure that internode communications are encrypted and verified, which is achieved with mutual TLS.
 
-Refer to [Transport TLS/SSL settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#transport-tls-ssl-settings) for the complete list of available settings in {{es}}.
+In a secured cluster, {{es}} nodes use certificates to identify themselves when communicating with other nodes.
 
-## Considerations for using an external CA
+The cluster must validate the authenticity of these certificates. The recommended approach is to trust a specific certificate authority (CA). When nodes are added to your cluster they must use a certificate signed by the same CA.
 
-You might choose to use an external CA to generate transport certificates for node-to-node connections.
+For the transport layer, we recommend using a separate, dedicated CA instead of an existing, possibly shared CA so that node membership is tightly controlled.
 
-Transport connections between {{es}} nodes are security-critical and you must protect them carefully. Malicious actors who can observe or interfere with unencrypted node-to-node transport traffic can read or modify cluster data. A malicious actor who can establish a transport connection might be able to invoke system-internal APIs, including APIs that read or modify cluster data.
+When you manually set up transport TLS, you can choose from the following CA options: 
 
-Carefully review [](/deploy-manage/security/self-tls-considerations.md) to ensure that the certificates that you provide meet the security requirements for transport connections.
+* [Provide certificates from a private or third-party CA](#private-3p)
+* [Use the `elasticsearch-certutil` tool to generate a CA unique to your cluster](#generate-certificates)
 
-## Generate the certificate authority [generate-certificates]
+### Provide certificates from a private or third-party CA [private-3p]
 
-You can add as many nodes as you want in a cluster but they must be able to communicate with each other. The communication between nodes in a cluster is handled by the transport module. To secure your cluster, you must ensure that internode communications are encrypted and verified, which is achieved with mutual TLS.
+You might choose to use a private or third-party CA to generate transport certificates for node-to-node connections.
 
-In a secured cluster, {{es}} nodes use certificates to identify themselves when communicating with other nodes.
+Transport connections between {{es}} nodes are security-critical and you must protect them carefully. Malicious actors who can observe or interfere with unencrypted node-to-node transport traffic can read or modify cluster data. A malicious actor who can establish a transport connection might be able to invoke system-internal APIs, including APIs that read or modify cluster data.
 
-The cluster must validate the authenticity of these certificates. The recommended approach is to trust a specific certificate authority (CA). When nodes are added to your cluster they must use a certificate signed by the same CA.
+Carefully review [](/deploy-manage/security/self-tls-considerations.md) to ensure that the certificates that you provide meet the security requirements for transport connections.
+
+After you obtain your certificate, place the certificate file in the `$ES_PATH_CONF` directory on **every** node in your cluster. 
 
-For the transport layer, we recommend using a separate, dedicated CA instead of an existing, possibly shared CA so that node membership is tightly controlled. Use the `elasticsearch-certutil` tool to generate a CA for your cluster.
+### Generate the certificate authority using `elasticsearch-certutil`  [generate-certificates]
+
+You can use the `elasticsearch-certutil` tool to generate a CA for your cluster. Using `elasticsearch-certutil` guarantees that your certificates meet {{es}} certificate requirements and security best practices. 
 
 1. Before starting {{es}}, use the `elasticsearch-certutil` tool on any single node to generate a CA for your cluster.
 
@@ -67,7 +78,7 @@ For the transport layer, we recommend using a separate, dedicated CA instead of
         1. Enter the password for your CA, or press **Enter** if you did not configure one in the previous step.
         2. Create a password for the certificate and accept the default file name.
 
-            The output file is a keystore named `elastic-certificates.p12`. This file contains a node certificate, node key, and CA certificate.
+            The output file is a keystore named `elastSic-certificates.p12`. This file contains a node certificate, node key, and CA certificate.
 
 3. On **every** node in your cluster, copy the `elastic-certificates.p12` file to the `$ES_PATH_CONF` directory.
 
@@ -76,7 +87,9 @@ For the transport layer, we recommend using a separate, dedicated CA instead of
 
 The transport networking layer is used for internal communication between nodes in a cluster. When security features are enabled, you must use TLS to ensure that communication between the nodes is encrypted.
 
-Now that you’ve generated a certificate authority and certificates, you’ll update your cluster to use these files.
+Now that you’ve obtained your certificates, you’ll update your cluster to use these files.
+
+These steps assume that you [generated a CA and certificates](#generate-certificates) using `elasticsearch-certutil`. The `xpack.security.transport.ssl` settings that you need to set differ if you're using a private or third-party CA. Refer to [Transport TLS/SSL settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#transport-tls-ssl-settings) full list of available settings.
 
 ::::{note}
 {{es}} monitors all files such as certificates, keys, keystores, or truststores that are configured as values of TLS-related node settings. If you update any of these files, such as when your hostnames change or your certificates are due to expire, {{es}} reloads them. The files are polled for changes at a frequency determined by the global {{es}} `resource.reload.interval.high` setting, which defaults to 5 seconds.