For SmartSync policies to run, trust must be established between the source and target cluster. Transport Layer Security (TLS) provides the authorization, authentication, and encryption, resulting in a mutual handshake. Each cluster requires configuration of a Certificate Authority (CA) and Certificate Identity (CI). SmartSync requires that encryption be configured for policies to run. The SmartSync daemon only runs after a CA and CI are configured.

Note: The source and target clusters establish trust by installing the CA that signed the other cluster’s CI. In a scenario of replication to multiple clusters, the CA of each cluster is installed on every cluster. SmartSync establishes a mutual TLS handshake, disallowing unidirectional trust.

Further enhancing SmartSync security, PowerScale OneFS release 9.5.0.0 provides SmartSync support for the Online Certificate Status Protocol (OCSP). This section provides encryption configuration steps without an OCSP. For more information about using an OCSP, see OCSP.

As a best practice, use a local CA to sign a CI per cluster.

• If a local CA is available, go to the Local Certificate Authority section.
• If a local CA is not available, go to the Self-signed certificates section.

Note: The SmartSync daemon does not start until a CA and CI is configured. For an example of log file output when a CA is not configured, see Unconfigured CAThe SmartSync daemon is required for SmartSync and Cloud Copy policies. Even if a cluster is only performing Cloud Copy, a CA and CI are still required for the SmartSync daemon to start. For deployments where a cluster is only performing Cloud Copy, a minimal CA and CI configuration is required, as explained in Minimum certificate configuration for Cloud Copy only clusters.

Local Certificate Authority

If a local CA is available, create the CA and CI bundles for the source and target clusters. The bundles must be X.509 public key infrastructure (PKI) certificates. The certificate formats supported are PEM, DEM, and PKCS #12 format.

If intermediates are required for the CA bundle, the order of the bundle begins with the CA certificate and ends with the root. This order includes any intermediates in between, excluding the CI. Each certificate must certify the certificate before it. For example, a certificate bundle could be in the following format:

• Intermediate certificate 3
• Intermediate certificate 2
• Intermediate certificate 1
• Root certificate

The CI bundle consists of the X.509 certificate followed by the private key. Optionally, the private key may also be encrypted and password protected in the CI bundle. If the private key is password protected, note the password for use in the steps that follow.

Once the CA and CI bundles are complete for the source and target clusters, transfer them to each cluster through any protocol, and retain the file location for use in the steps that follow. Next, go to Install Certificate Authority and Certificate Identity.

Self-signed certificates

If a local CA is not available, self-signed certificates may be used.

Note: Using a local CA is a best practice for an optimal security posture. Only use the self-signed certificate option if a local CA is unavailable.

The same CA could be used on the source and target cluster with the self-signed certificates option. However, this section provides steps to configure a CA on each cluster, and the CA signs its local CI for a more secure option.

To configure encryption with self-signed certificates, perform the following steps.

1. Log in to the source cluster CLI. On the source cluster, generate a CA:

source-cluster# openssl genrsa -out ca-s.key 4096

source-cluster# openssl req -x509 -new -nodes -key ca-s.key -sha256 -days 1825 -out ca-s.pem

2. Copy the source cluster CA to the target cluster:

source-cluster# scp ca-s.pem [Target Cluster IP]:/root

3. Generate the CI on the source cluster:

source-cluster# openssl genrsa -out identity-s.key 4096

source-cluster# openssl req -new -key identity-s.key -out identity-s.csr

4. Create the source cluster CI on the source cluster:

source-cluster# cat << EOF > identity-s.ext

authorityKeyIdentifier=keyid,issuer​

basicConstraints=CA:FALSE

keyUsage=digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment

EOF

5. On the source cluster, sign the source cluster’s CI with the source cluster’s CA:

source-cluster# openssl x509 -req -in identity-s.csr -CA ca-s.pem -CAkey ca-s.key -CAcreateserial -out identity-s.crt -days 825 -sha256 -extfile identity-s.ext

6. Log in to the target cluster CLI. On the target cluster, generate a CA:

target-cluster# openssl genrsa -out ca-t.key 4096

target-cluster# openssl req -x509 -new -nodes -key ca-t.key -sha256 -days 1825 -out ca-t.pem

7. Copy the target cluster CA to the source cluster:

target-cluster# scp ca-t.pem [Source Cluster IP]:/root

8. Generate the CI on the target cluster:

target-cluster# openssl genrsa -out identity-t.key 4096

target-cluster# openssl req -new -key identity-t.key -out identity-t.csr

9. Create the target cluster CI on the target cluster:

target-cluster# cat << EOF > identity-t.ext

authorityKeyIdentifier=keyid,issuer

basicConstraints=CA:FALSE

keyUsage=digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment

EOF

10. On the target cluster, sign the target cluster’s CI with the target cluster’s CA:

target-cluster# openssl x509 -req -in identity-t.csr -CA ca-t.pem -CAkey ca-t.key -CAcreateserial -out identity-t.crt -days 825 -sha256 -extfile identity-t.ext

The self-signed certificates for the source and target clusters are now generated. Continue with Install Certificate Authority and Certificate Identity.

Install Certificate Authority and Certificate Identity

The CAs and CIs for each cluster are generated and copied to the appropriate cluster. Before you continue with this section, ensure that the location of all certificates is under the /ifs tree and make note of the location. The examples below do not list a certificate location, but the location must be under the /ifs tree.

The steps that follow assume a naming convention of -s to notate the source cluster and -t to notate the target cluster. If a local CA generated the bundles, replace the naming convention in the following steps with the actual name and location of the bundles. The example assumes that a unique CA is installed on each cluster. If the same CA is installed on each cluster, skip the step for a second CA.

To install the CA and CI, perform the following steps:

1. On the source cluster, install the source cluster’s CA:

source-cluster# isi dm certificates ca create "$PWD"/ca-s.pem --name cluster-s-ca

2. On the source cluster, install the target cluster’s CA:

source-cluster# isi dm certificates ca create "$PWD"/ca-t.pem --name cluster-t-ca

3. On the source cluster, install the source cluster’s CI:

source-cluster# isi dm certificates identity create "$PWD"/identity-s.crt --certificate-key-path "$PWD"/identity-s.key --name cluster-s-identity

Note: If the identity has a password configured, use the --certificate-key-password option to specify the password.

4. On the target cluster, install the target cluster’s CA:

target-cluster# isi dm certificates ca create "$PWD"/ca-t.pem --name cluster-t-ca

5. On the target cluster, install the source cluster’s CA:

target-cluster# isi dm certificates ca create "$PWD"/ca-s.pem --name cluster-s-ca

6. On the target cluster, install the target cluster’s CI:

target-cluster# isi dm certificates identity create "$PWD"/identity-t.crt --certificate-key-path "$PWD"/identity-t.key --name cluster-t-identity

Note: If the identity has a password configured, use the --certificate-key-password option to specify the password.

Encryption is now configured on the source and target clusters. The SmartSync daemon is now active. To confirm if the daemon is active, check if it has a PID by running pgrep isi_dm_d. Proceed with the replication account creation in the Replication accounts Section.

OCSP

OneFS release 9.5.0.0 provides SmartSync support for OCSP, as required for federal FIPS and STIG requirements. To configure OCSP, run the isi dm certificates settings modify command. The following options are available:

• Enable-encryption: This option enables traffic encryption. If the option is disabled, an initial successful TLS handshake is required, but SmartSync replication traffic is not encrypted.
• Strict-hostname-check: This option requires the CN/ASN found in the certificate to match the account URI; otherwise, the handshake fails.
• OCSP-URI: If the certificate does not already contain the OCSP URI, it may be provided with this option.
• Revocation-setting: This option specifies the level of OCSP checking. The following options are available:

• Strict: Requires all handshakes to pass OCSP. All OCSP check failures are considered fatal.
• Allow revoke data unavailable: Requires the OCSP checks to pass, but if an OCSP responder is unavailable, the check is successful.
• Allow no revoke SRC: Requires the OCSP checks to pass even if a certificate does not contain a URI.
• None: Bypasses all OCSP checks.

Minimum certificate configuration for Cloud Copy only clusters

For clusters that are only performing file-to-object copy through Cloud Copy, a minimum certification configuration is required to activate the SmartSync daemon. If a cluster is performing a file replication between PowerScale clusters, the full certification configuration must be implemented, as explained in the previous section. The steps in this section provided the minimum level of certificates to activate the SmartSync daemon. To activate the SmartSync daemon for Cloud Copy, perform the following:

1. Log in to the source cluster CLI. On the source cluster, generate a CA:

source-cluster# openssl genrsa -out ca-s.key 4096

source-cluster# openssl req -x509 -new -nodes -key ca-s.key -sha256 -days 1825 -out ca-s.pem

2. Generate the CI on the source cluster:

source-cluster# openssl genrsa -out identity-s.key 4096

source-cluster# openssl req -new -key identity-s.key -out identity-s.csr

3. Create the source cluster CI on the source cluster:

source-cluster# cat << EOF > identity-s.ext

authorityKeyIdentifier=keyid,issuer​

basicConstraints=CA:FALSE

keyUsage=digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment

EOF

4. On the source cluster, sign the source cluster’s CI with the source cluster’s CA:

source-cluster# openssl x509 -req -in identity-s.csr -CA ca-s.pem -CAkey ca-s.key -CAcreateserial -out identity-s.crt -days 825 -sha256 -extfile identity-s.ext

5. On the source cluster, install the source cluster’s CA:

source-cluster# isi dm certificates ca create "$PWD"/ca-s.pem --name cluster-s-ca

6. On the source cluster, install the source cluster’s CI:

source-cluster# isi dm certificates identity create "$PWD"/identity-s.crt --certificate-key-path "$PWD"/identity-s.key --name cluster-s-identity

The SmartSync daemon is now active. To confirm if the daemon is active, check if it has a PID by running pgrep isi_dm_d. Proceed with the replication account creation in the Replication accounts Section.