DOC-5210 Added new section for customer-managed internode encryption certificates

Author: rrelledge

content/operate/rs/security/encryption/internode-encryption.md

@@ -87,7 +87,11 @@ To enable internode encryption for new databases by default, use one of the foll
     { "data_internode_encryption": true }
     ```
 
-## Encryption ciphers and settings
+## Self-signed certificates
+
+By default, Redis Enterprise Software uses self-signed certificates for internode encryption. These certificates are automatically generated, managed, and rotated by the system.
+
+### Encryption ciphers and settings
 
 To encrypt internode communications, Redis Enterprise Software uses TLS 1.2 and the following cipher suites:
 
@@ -103,7 +107,7 @@ The TLS layer determines which TLS version to use.
 
 No configurable settings are exposed; internode encryption is used internally within a cluster and not exposed to any outside service.
 
-## Certificate authority and rotation
+### Certificate authority and rotation
 
 Starting with v6.2.4, internode communication is managed, in part, by two certificates: one for the control plane and one for the data plane.  These certificates are signed by a private certificate authority (CA).  The CA is not exposed outside of the cluster, so it cannot be accessed by external processes or services.  In addition, each cluster generates a unique CA that is not used anywhere else.
 
@@ -118,3 +122,89 @@ You can use the Redis Enterprise Software REST API to rotate certificates manual
 ``` rest
 POST /v1/cluster/certificates/rotate
 ```
+
+## Customer-provided certificates
+
+Instead of using Redis Enterprise Software's self-signed certificates for internode encryption, you can provide your own certificates generated by your Certificate Authority (CA).
+
+### Certificate requirements
+
+Customer-provided internode encryption certificates must meet the following requirements:
+
+- Certificates must be in PEM format.
+
+- Certificates must contain the certificate chain and the leaf certificate.
+
+### Upload customer-provided certificates
+
+You can upload either:
+
+- One certificate to be used for both data plane internode encryption (DPINE) and control plane internode encryption (CPINE)
+
+- Two separate certificates: one for DPINE and one for CPINE
+
+
+{{< multitabs id="get-module-versions" 
+tab1="Cluster Manager UI"
+tab2="rladmin"
+tab3="REST API" >}}
+
+1. In the Cluster Manager UI, go to **Cluster > Security > Certificates**.
+
+1. Expand the **Internode encryption certificates** section.
+
+1. Click **Replace certificates**.
+
+1. In the **Internode encryption certificates** panel, select one of the following options:
+
+    - Use the same certificate for data and control plane internode encryption
+
+    - Use separate certificates for data and control plane internode encryption
+
+1. For each certificate and key, click **Upload** and use the file browser to select the relevant PEM file.
+
+1. Click **Save & Rotate**.
+
+-tab-sep-
+
+<!-- TODO: these are placeholder examples, need to confirm real commands-->
+
+Run [`rladmin cluster certificate`]({{< relref "/operate/rs/references/cli-utilities/rladmin/cluster/certificate" >}}).
+
+To upload a single certificate for both CPINE and DPINE:
+
+```sh
+rladmin cluster certificate set cpine_dpine certificate_file <cert1>.pem key_file <key1>.pem
+```
+
+To upload 2 different certificate and key pairs for CPINE and DPINE:
+
+```sh
+rladmin cluster certificate set cpine certificate_file <cert1>.pem key_file <key1>.pem dpine certificate_file <cert2>.pem key_file <key2>.pem
+```
+
+-tab-sep-
+
+<!-- TODO: these are placeholder examples, need to confirm real API-->
+
+Send a [`PUT /v1/certificates`]({{< relref "/operate/rs/references/rest-api/requests/certificates#put-certificates" >}}) request:
+
+```sh
+PUT https://<host>:<port>/v1/certificates
+```
+
+{{< /multitabs >}}
+
+
+### Certificate expiration and rotation
+
+Customer-provided internode encryption certificates are not rotated automatically.
+
+The expiration of internode encryption certificates could lead to unavailability of the cluster and its databases. To prevent this issue, you should monitor the certificates' expiration dates and renew them before they expire.
+
+In case the customer-managed certificates are not manually renewed before they expire, Redis Enterprise Software automatically replaces them with self-signed certificates 5 days before expiration. You can upload new customer-provided certificates at any time to replace the automatically generated self-signed certificates.
+
+### Performance recommendations
+
+For optimal performance with customer-provided certificates, follow the same recommendations as for self-signed certificates detailed in the [Encryption ciphers and settings](#encryption-ciphers-and-settings) section.
+