use external instead of private/3p

Author: shainaraskas

deploy-manage/security/_snippets/own-ca-warning.md

@@ -1,5 +1,5 @@
 :::{warning}
 Transport connections between {{es}} nodes are security-critical and you must protect them carefully. Malicious actors who can observe or interfere with 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.
 
-If you choose to issue node transport certificates using third-party tools, then carefully review [](/deploy-manage/security/self-tls-considerations.md) to ensure that the certificates that you provide meet the security requirements for transport connections.
+If you choose to issue node transport certificates using an external CA, then carefully review [](/deploy-manage/security/self-tls-considerations.md) to ensure that the certificates that you provide meet the security requirements for transport connections.
 :::

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

@@ -6,10 +6,10 @@ applies_to:
     eck:
 products:
   - id: elasticsearch
-navigation_title: Private or 3P CA considerations
+navigation_title: External CA considerations
 ---
 
-# Considerations for using a private or third-party CA for transport layer security
+# Considerations for using an external 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`. 
 
@@ -19,7 +19,7 @@ By default, {{es}} uses mutual TLS (mTLS) to secure node-to-node transport conne
 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.
 ::::
 
-## mTLS transport certificate requirements for private or third-party CAs
+## mTLS transport certificate requirements for external 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

@@ -41,7 +41,7 @@ For the transport layer, we recommend using a separate, dedicated CA instead of
 When you manually set up transport TLS, you can choose from the following CA options: 
 
 * [Use the `elasticsearch-certutil` tool to generate a CA unique to your cluster](#generate-certificates) (recommended)
-* [Provide certificates from a private or third-party CA](#private-3p)
+* [Provide certificates from an external CA](#external-ca)
 
 ### Generate the certificate authority using `elasticsearch-certutil`  [generate-certificates]
 
@@ -71,9 +71,9 @@ You can use the `elasticsearch-certutil` tool to generate a CA for your cluster.
             The output file is a keystore named `elastic-certificates.p12`. This file contains a node certificate, node key, and CA certificate.
 
 
-### Provide certificates from a private or third-party CA [private-3p]
+### Provide certificates from an external CA [external-ca]
 
-You might choose to use a private or third-party CA to generate transport certificates for node-to-node connections.
+You might choose to use an external CA to generate transport certificates for node-to-node connections. An external CA is any CA that is not managed using `elasticsearch-certutil`.
 
 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.
 
@@ -86,7 +86,7 @@ The transport networking layer is used for internal communication between nodes
 
 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 certificate generated with 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.
+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 certificate generated with an external 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.