[[remote-clusters-cert]]
=== Add remote clusters using TLS certificate authentication

To add a remote cluster using TLS certificate authentication:

. <<remote-clusters-prerequisites-cert,Review the prerequisites>>
. <<remote-clusters-security-cert>>
. <<remote-clusters-connect-cert>>
. <<remote-clusters-privileges-cert>>

If you run into any issues, refer to <<remote-clusters-troubleshooting>>.

[[remote-clusters-prerequisites-cert]]
==== Prerequisites

. The {es} security features need to be enabled on both clusters, on every node.
Security is enabled by default. If it's disabled, set `xpack.security.enabled`
to `true` in `elasticsearch.yml`. Refer to <<general-security-settings>>.
. The local and remote clusters versions must be compatible.
** Any node can communicate with another node on the same
major version. For example, 7.0 can talk to any 7.x node.
** Only nodes on the last minor version of a certain major version can
communicate with nodes on the following major version. In the 6.x series, 6.8
can communicate with any 7.x node, while 6.7 can only communicate with 7.0.
** Version compatibility is
symmetric, meaning that if 6.7 can communicate with 7.0, 7.0 can also
communicate with 6.7. The following table depicts version compatibility between
local and remote nodes.
+
[%collapsible%open]
.Version compatibility table
====
include::../remote-clusters-shared.asciidoc[tag=remote-cluster-compatibility-matrix]
====
+
IMPORTANT: Elastic only supports {ccs} on a subset of these configurations. See
<<ccs-supported-configurations>>.

[[remote-clusters-security-cert]]
==== Establish trust with a remote cluster

To use {ccr} or {ccs} safely with remote clusters, enable security on all 
connected clusters and configure Transport Layer Security (TLS) on every node.
Configuring TLS security on the transport interface is minimally required for
remote clusters. For additional security, configure TLS on the
<<security-basic-setup-https,HTTP interface>> as well.

All connected clusters must trust one another and be mutually authenticated
with TLS on the transport interface. This means that the local cluster
trusts the certificate  authority (CA) of the remote cluster, and the remote
cluster trusts the CA of the local cluster. When establishing a connection, all
nodes will verify certificates from nodes on the other side. This mutual trust
is required to securely connect a remote cluster, because all connected nodes
effectively form a single security domain.

User authentication is performed on the local cluster and the user and user’s
roles names are passed to the remote clusters. A remote cluster checks the
user’s role names against its local role definitions to determine which indices
the user is allowed to access.

Before using {ccr} or {ccs} with secured {es} clusters, complete the following 
configuration task:

. Configure Transport Layer Security (TLS) on every node to encrypt internode
traffic and authenticate nodes in the local cluster with nodes in all remote
clusters. Refer to 
<<security-basic-setup,set up basic security for the {stack}>> for the required
steps to configure security.
+
NOTE: This procedure uses the same CA to generate certificates for all nodes.
Alternatively, you can add the certificates from the local cluster as a
trusted CA in each remote cluster. You must also add the certificates from
remote clusters as a trusted CA on the local cluster. Using the same CA to
generate certificates for all nodes simplifies this task.

[[remote-clusters-connect-cert]]
==== Connect to a remote cluster

:trust-mechanism: cert
include::remote-clusters-connect.asciidoc[]
:!trust-mechanism: 

include::{es-repo-dir}/security/authentication/remote-clusters-privileges-cert.asciidoc[leveloffset=+1]